xhci_hub_report_usb3_link_state() returns pls as U0 when the link
is in resume state, and this causes usb core to think the link is in
U0 while actually it's in resume state. When usb core transfers
control request on the link, it fails with TRB error as the link
is not ready for transfer.
To fix the issue, report U3 when the link is in resume state, thus
usb core knows the link it's not ready for transfer.
Cc: <stable@vger.kernel.org>
Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When resetting a device the number of active TTs may need to be
corrected by xhci_update_tt_active_eps, but the number of old active
endpoints supplied to it was always zero, so the number of TTs and the
bandwidth reserved for them was not updated, and could rise
unnecessarily.
This affected systems using Intel's Patherpoint chipset, which rely on
software bandwidth checking. For example, a Lenovo X230 would lose the
ability to use ports on the docking station after enough suspend/resume
cycles because the bandwidth calculated would rise with every cycle when
a suitable device is attached.
The correct number of active endpoints is calculated in the same way as
in xhci_reserve_bandwidth.
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Campbell <bacam@z273.org.uk>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
virt_dev->num_cached_rings counts on freed ring and is not updated
correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
is added into cache and then num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, current index should be decremented
first and then corresponding ring buffer value should be taken from ring
cache.
But In function xhci_endpoint_init(), the num_rings_cached index is
accessed before decrement.
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
Cc: <stable@vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep@samsung.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The xHCI in Intel CherryView / Braswell Platform requires
a driver workaround to get xHCI D3 working. Without this
workaround, xHCI might not enter D3.
Workaround is to configure SSIC PORT as "unused" before D3
entry and "used" after D3 exit. This is done through a
vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset
0x883c), in xhci suspend / resume callbacks.
Verified xHCI D3 works fine in CherryView / Braswell platform.
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled
xhci from going to D3 state in runtime suspend. Driver needs to verify
it can deal with the hw by calling an ACPI _DSM method to get D3 enabled.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I'm not aware of any existing bugs around this, but the expectation is
that nfs_mark_for_revalidate() should always force a revalidation of
the cached metadata.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Setting the change attribute has been mandatory for all NFS versions, since
commit 3a1556e866 ("NFSv2/v3: Simulate the change attribute"). We should
therefore not have anything be conditional on it being set/unset.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
We can't allow caching of data until the change attribute has been
initialised correctly.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
If we've ensured that the size and the change attribute are both correct,
then there is no point in marking those attributes as needing revalidation
again. Only do so if we know the size is incorrect and was not updated.
Fixes: f2467b6f64 ("NFS: Clear NFS_INO_REVAL_PAGECACHE when...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
pNFS writes don't return attributes, however that doesn't mean that we
should ignore the fact that they may be extending the file. This patch
ensures that if a write is seen to extend the file, then we always set
an attribute barrier, and update the cached file size.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Otherwise, nfs4_select_rw_stateid() will always return the zero stateid
instead of the correct open stateid.
Fixes: f95549cf24 ("NFSv4: More CLOSE/OPEN races")
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Calling xprt_complete_bc_request() effectively causes the slot to be allocated,
so it needs to decrement the backchannel free slot count as well.
Fixes: 0d2a970d0a ("SUNRPC: Fix a backchannel race")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
deadlocking, since it already holds the xprt->bc_pa_lock.
Reported-by: Chuck Lever <chuck.lever@oracle.com>
Fixes: 0d2a970d0a ("SUNRPC: Fix a backchannel race")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
end_cmd finishes request associated with nullb_cmd struct, so we
should save pointer to request_queue in a local variable before
calling end_cmd.
The problem was causes general protection fault with slab poisoning
enabled.
Fixes: 8b70f45e2e ("null_blk: restart request processing on completion handler")
Tested-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Only four fixes this time so I'll describe them all.
We have an iomen resource leak fix in mv_udc_core. This bug
exists since v3.3.
Renesas got a fix for how they use dma_map_single() with IOMMU.
The new ulpi bus got an ordering fix, so drivers don't try to
probe ahead of the bus.
And finally, we have a fix for a really old regression with
dwc3, one which could only be exposed by a recent patch from
Subbaraya. Basically, we were startving the controller of
transfer resources.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVr6KCAAoJEIaOsuA1yqREx4cP/RolxrMYns+Buo0cXJppqN4I
xN4iKtFN91GEp6+QV+KCeo5fNEtbsMeJEKoj0Xo0L5gk5ArKaChY9AqPAbepsA0J
mO6fqMFJMzJiwc9aH/VBisEcmx44SogyH2wke/BSdQLYrQO4Tgs0trNLVu5IWPaw
WGOwrsdcGu18swW3mzLe+bqL69GRENIiOcZJD3it0NBUDUNaaWwLXKz6ncu651iE
DsDMef0Ib2JQj23pWYMYsz727Cj1rwciy4pf5iuNBY44/TltuRNCSTavf3MZfQtP
DxaVQhySGr4Bv+312JEBEbx+lxzQg3qHCUd2T2CSTFzGHpqjuzpmYpXuCPuYifcv
mJZPymqiLxDJgSgu5bIvBZif+7SGvg5AEoYUQsQildwSrcW2lpxtkhCFWnPzkrEj
YYdh7wGEYtiUpLB3paa5HjaoFVkopXDlg1YcTCoPVsnLmV22q2ciSigYDTsfh4oV
hEU95RiIN+Qm3HPcnPyYGqr30OlH/lDfxGnaSOTeMtWCPu82mR5opTsW+bzQa463
HzF7thJf4AjZqdCczi3YELo7sAjUa77ANa2KDxu0DlbPB5AsFOTP/4Hy8eNb7MsO
b91dSQipQuixeeHJqYo3G+jp1Gtt7KuqwrrG+0l8oM5YTapRONKf6d4JiFPG2A56
iBkACDBoZiXH7idSX48b
=eKH4
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v4.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v4.2-rc4
Only four fixes this time so I'll describe them all.
We have an iomen resource leak fix in mv_udc_core. This bug
exists since v3.3.
Renesas got a fix for how they use dma_map_single() with IOMMU.
The new ulpi bus got an ordering fix, so drivers don't try to
probe ahead of the bus.
And finally, we have a fix for a really old regression with
dwc3, one which could only be exposed by a recent patch from
Subbaraya. Basically, we were startving the controller of
transfer resources.
Signed-off-by: Felipe Balbi <balbi@ti.com>
task_struct and the asm offsets becoming too large for the AArch64 ISA
- preparatory patch for moving irq_data struct members (applied now to
reduce dependency for the next merging window)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVr5iXAAoJEGvWsS0AyF7x+j4P/Ak5EnDp9k+q8gn4Q+xd+XWS
2i/43LgH0Q4n1BruttzYGIzYHVP3j1TVy41dIcQeFTf3nubl7Pz197H63t8lY51I
C9wiMjavWZ8YetzHsE+3K/7NkuHYom5q0V9PmzgzQ/DXVfgv8G2F1iwoBqXlfhxg
N0UTZKzr0dx9jxPmmHBThuReAjiDeLK2qLXiNpbUwAUyfTWq+Q/NQWxuBBqTCjd9
biICv0kFHVI0UH39Q9K78xi4VZ9fpcmsb5mTiijbGJTgLqrC+XkSCIBiKmMm/2sI
lxS5mKcprCh4X1xaBSQ/iyAqWOyZ5Z0oTV7b9dLN0Ai+0cnAIYuYkFeCZwvrfhXz
bg4O0lY91QzXn6SVBgu6i/coblR/O8s49VqRpqoFZogCQHAdBstjzLo9IFUp16To
Dv2I1pn3Z8qCbeRXZdRYLa5/WKfjdWkTkW8ucyX97eE4N/PSa4213w37HUOtPboE
HAGJpahrAbeYE+6AViZwUQ8QT0Q6UESm4OtOV5lP/m9vxVDq38uxHUK7ilqHhJt7
yDvIr5Ufvi4g0Grj9SGSuAa2c1C3GV2eTBekXeZ5w+VAo2ITVGx6xSVpsA7PFYP9
vS6j9X0oNR5LXkGRZW2sxbQZsRPnQBeQuSopo4CuRD9aszKS4XrCJ+R1U8EM/ixi
82fmhx1hjwJPkTcds9lY
=GPY8
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull ARM64 fixes from Catalin Marinas:
- arm64 build fix following the move of the thread_struct to the end of
task_struct and the asm offsets becoming too large for the AArch64
ISA
- preparatory patch for moving irq_data struct members (applied now to
reduce dependency for the next merging window)
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
ARM64/irq: Use access helper irq_data_get_affinity_mask()
arm64: switch_to: calculate cpu context pointer using separate register
region_is_ram() looks up the iomem_resource table to check if
a target range is in RAM. However, it always returns with -1
due to invalid range checks. It always breaks the loop at the
first entry of the table.
Another issue is that it compares p->flags and flags, but it always
fails. flags is declared as int, which makes it as a negative value
with IORESOURCE_BUSY (0x80000000) set while p->flags is unsigned long.
Fix the range check and flags so that region_is_ram() works as
advertised.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Roland Dreier <roland@purestorage.com>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-4-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
__ioremap_caller() calls region_is_ram() to walk through the
iomem_resource table to check if a target range is in RAM, which was
added to improve the lookup performance over page_is_ram() (commit
906e36c5c7 "x86: use optimized ioresource lookup in ioremap
function"). page_is_ram() was no longer used when this change was
added, though.
__ioremap_caller() then calls walk_system_ram_range(), which had
replaced page_is_ram() to improve the lookup performance (commit
c81c8a1eee "x86, ioremap: Speed up check for RAM pages").
Since both checks walk through the same iomem_resource table for
the same purpose, there is no need to call both functions.
Aside of that walk_system_ram_range() is the only useful check at the
moment because region_is_ram() always returns -1 due to an
implementation bug. That bug in region_is_ram() cannot be fixed
without breaking existing ioremap callers, which rely on the subtle
difference of walk_system_ram_range() versus non page aligned ranges.
Once these offending callers are fixed we can use region_is_ram() and
remove walk_system_ram_range().
[ tglx: Massaged changelog ]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-3-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
__ioremap_check_ram() has a WARN_ONCE() which is emitted when the
given pfn range is not RAM. The warning is bogus in two aspects:
- it never triggers since walk_system_ram_range() only calls
__ioremap_check_ram() for RAM ranges.
- the warning message is wrong as it says: "ioremap on RAM' after it
established that the pfn range is not RAM.
Move the WARN_ONCE() to __ioremap_caller(), and update the message to
include the address range so we get an actual warning when something
tries to ioremap system RAM.
[ tglx: Massaged changelog ]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/1437088996-28511-2-git-send-email-toshi.kani@hp.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
When zones were originally introduced, the expectation functions were
all extended to perform lookup using the zone. However, insertion was
not modified to check the zone. This means that two expectations which
are intended to apply for different connections that have the same tuple
but exist in different zones cannot both be tracked.
Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This fixes an issue introduced in commit b23c843992 (usb: dwc3:
gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
only use DEPSTARTCFG once per SetConfig.
The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
SetInterface. SetInterface was completely missed from the original
patch.
This problem became aparent after commit 76e838c9f7 (usb: dwc3:
gadget: return error if command sent to DEPCMD register fails)
added checking of the return status of device endpoint commands.
'Set Endpoint Transfer Resource' command was caught failing
occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.
Finally, to fix the issue, was we have to do is make sure that
our start_config_issued flag gets reset whenever we receive a
SetInterface request.
To verify the problem (and its fix), all we have to do is run
test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
Tested-by: Huang Rui <ray.huang@amd.com>
Tested-by: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes: b23c843992 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Mar 6 12:36:42 2015 +0000
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos <tiagomatos@gmail.com>
Cc: Julien Wajsberg <felash@gmail.com>
Cc: kuddel.mail@gmx.de
Cc: Lennart Poettering <mzxreary@0pointer.de>
Cc: stable@vger.kernel.org
Acked-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rui Tiago Cação Matos <tiagomatos@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is a preparatory patch for moving irq_data struct members.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Commit 0c8c0f03e3 ("x86/fpu, sched: Dynamically allocate 'struct fpu'")
moved the thread_struct to the bottom of task_struct. As a result, the
offset is now too large to be used in an immediate add on arm64 with
some kernel configs:
arch/arm64/kernel/entry.S: Assembler messages:
arch/arm64/kernel/entry.S:588: Error: immediate out of range
arch/arm64/kernel/entry.S:597: Error: immediate out of range
This patch calculates the offset using an additional register instead of
an immediate offset.
Fixes: 0c8c0f03e3 ("x86/fpu, sched: Dynamically allocate 'struct fpu'")
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The regmap_write in ssm4567_set_dai_fmt accidentally clears the
TDM_BCLKS field which was set earlier by ssm4567_set_tdm_slot.
This patch fixes it by using regmap_update_bits with proper mask.
Signed-off-by: Ben Zhang <benzh@chromium.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Currently, below code actually does not update any bit because
SGTL5000_SMALL_POP is 0.
snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, SGTL5000_SMALL_POP, 1);
The SGTL5000_SMALL_POP should be BIT(0) rather than 0, fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-By: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Without this patch, the headset mic will not work on this machine.
BugLink: https://bugs.launchpad.net/bugs/1476987
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
One more Dell laptop with alc293 codec needs
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE, but the pin 0x1e does not match
the corresponding one in the ALC292_STANDARD_PINS. To use this macro
for this machine, we need to remove pin 0x1e from it.
BugLink: https://bugs.launchpad.net/bugs/1476888
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The driver is written as if it can adapt to a low memory situation allocating
less RX skbs and TX aligned buffers than the respective RX/TX ring sizes. In
reality though the driver would malfunction in this case. Stop being overly
smart and just fail in such situation -- this is achieved by moving the memory
allocation from ravb_ring_format() to ravb_ring_init().
We leave dma_map_single() calls in place but make their failure non-fatal
by marking the corresponding RX descriptors with zero data size which should
prevent DMA to an invalid addresses.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix warning: logical ‘or’ of collectively exhaustive tests is always true
Change the internal delay check from an 'or' condition to an 'and'
condition.
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some architectures like POWER can have a NUMA node_possible_map that
contains sparse entries. This causes memory corruption with openvswitch
since it allocates flow_cache with a multiple of num_possible_nodes() and
assumes the node variable returned by for_each_node will index into
flow->stats[node].
Use nr_node_ids to allocate a maximal sparse array instead of
num_possible_nodes().
The crash was noticed after 3af229f2 was applied as it changed the
node_possible_map to match node_online_map on boot.
Fixes: 3af229f207
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Nicolas Schichan says:
====================
BPF JIT fixes for ARM
These patches are fixing bugs in the ARM JIT and should probably find
their way to a stable kernel. All 60 test_bpf tests in Linux 4.1 release
are now passing OK (was 54 out of 60 before).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This makes BPF_ANC | SKF_AD_VLAN_TAG and BPF_ANC | SKF_AD_VLAN_TAG_PRESENT
have the same behaviour as the in kernel VM and makes the test_bpf LD_VLAN_TAG
and LD_VLAN_TAG_PRESENT tests pass.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Previously, the JIT would reject negative offsets known during code
generation and mishandle negative offsets provided at runtime.
Fix that by calling bpf_internal_load_pointer_neg_helper()
appropriately in the jit_get_skb_{b,h,w} slow path helpers and by forcing
the execution flow to the slow path helpers when the offset is
negative.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
To check whether the load should take the fast path or not, the code
would check that (r_skb_hlen - load_order) is greater than the offset
of the access using an "Unsigned higher or same" condition. For
halfword accesses and an skb length of 1 at offset 0, that test is
valid, as we end up comparing 0xffffffff(-1) and 0, so the fast path
is taken and the filter allows the load to wrongly succeed. A similar
issue exists for word loads at offset 0 and an skb length of less than
4.
Fix that by using the condition "Signed greater than or equal"
condition for the fast path code for load orders greater than 0.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Morton reported following warning on one ARM build
with gcc-4.4 :
net/ipv4/inet_hashtables.c: In function 'inet_ehash_locks_alloc':
net/ipv4/inet_hashtables.c:617: warning: division by zero
Even guarded with a test on sizeof(spinlock_t), compiler does not
like current construct on a !CONFIG_SMP build.
Remove the warning by using a temporary variable.
Fixes: 095dc8e0c3 ("tcp: fix/cleanup inet_ehash_locks_alloc()")
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The 'event_work' worker used by dm-raid may still be running
when the array is stopped. This can result in an oops.
So flush the workqueue on which it is run after detaching
and before destroying the device.
Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: stable@vger.kernel.org (2.6.38+ please delay 2 weeks after -final release)
Fixes: 9d09e663d5 ("dm: raid456 basic support")
'reshape_position' tracks where in the reshape we have reached.
'reshape_safe' tracks where in the reshape we have safely recorded
in the metadata.
These are compared to determine when to update the metadata.
So it is important that reshape_safe is initialised properly.
Currently it isn't. When starting a reshape from the beginning
it usually has the correct value by luck. But when reducing the
number of devices in a RAID10, it has the wrong value and this leads
to the metadata not being updated correctly.
This can lead to corruption if the reshape is not allowed to complete.
This patch is suitable for any -stable kernel which supports RAID10
reshape, which is 3.5 and later.
Fixes: 3ea7daa5d7 ("md/raid10: add reshape support")
Cc: stable@vger.kernel.org (v3.5+ please wait for -final to be out for 2 weeks)
Signed-off-by: NeilBrown <neilb@suse.com>
Cache size can grow or shrink due to various pressures at
any time. So when we resize the cache as part of a 'grow'
operation (i.e. change the size to allow more devices) we need
to blocks that automatic growing/shrinking.
So introduce a mutex. auto grow/shrink uses mutex_trylock()
and just doesn't bother if there is a blockage.
Resizing the whole cache holds the mutex to ensure that
the correct number of new stripes is allocated.
This bug can result in some stripes not being freed when an
array is stopped. This leads to the kmem_cache not being
freed and a subsequent array can try to use the same kmem_cache
and get confused.
Fixes: edbe83ab4c ("md/raid5: allow the stripe_cache to grow and shrink.")
Cc: stable@vger.kernel.org (4.1 - please delay until 2 weeks after release of 4.2)
Signed-off-by: NeilBrown <neilb@suse.com>
This reverts commit a2673b6e04.
Kinglong Mee reports a memory leak with that patch, and Jan Kara confirms:
"Thanks for report! You are right that my patch introduces a race
between fsnotify kthread and fsnotify_destroy_group() which can result
in leaking inotify event on group destruction.
I haven't yet decided whether the right fix is not to queue events for
dying notification group (as that is pointless anyway) or whether we
should just fix the original problem differently... Whenever I look
at fsnotify code mark handling I get lost in the maze of locks, lists,
and subtle differences between how different notification systems
handle notification marks :( I'll think about it over night"
and after thinking about it, Jan says:
"OK, I have looked into the code some more and I found another
relatively simple way of fixing the original oops. It will be IMHO
better than trying to fixup this issue which has more potential for
breakage. I'll ask Linus to revert the fsnotify fix he already merged
and send a new fix"
Reported-by: Kinglong Mee <kinglongmee@gmail.com>
Requested-by: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* fix device ID check for AR956x
iwlwifi:
* bug fixes specific for 8000 series
* fix a crash in time events
* fix a crash in PCIe transport
* fix BT Coex code that prevented association on certain
devices (3160).
* revert the new RBD allocation model because it introduced
a bug when running on weak VM setups.
* new device IDs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJVrQ65AAoJEG4XJFUm622bArgH/jlGm44aPLVTtTfc3Qi/yH1m
pVZ+F6Z4FhFM8Ln/skL/PIWPbxmcwMQ9IYiDI+1y0obr5RaNGZbh5EBwLcNQzAII
L9aO7vGGQRHewJj3LAY4ovkT7xYT6Kra4iZuXrozeq8CJN2/0l4Yv2uPkwPtszIf
Gp1QGgCbvUzaPdIIevx4bMyLcC5h58y7Thg2+kxSSo/VFJxGh2DFFnLuJx5RVS1D
r7fBWH5BzUPP1sh84Gt+0IpjyoxqpWiI//Wqg2Hkt6zdis3fixDvK8Wm08EewZdj
Wf63HgOzQeL9vE6IHg3WuUiR8QOn51+oqDWCtbrRemBsywZ9rc4vesMAREjcw2Q=
=ygb2
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2015-07-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
ath9k:
* fix device ID check for AR956x
iwlwifi:
* bug fixes specific for 8000 series
* fix a crash in time events
* fix a crash in PCIe transport
* fix BT Coex code that prevented association on certain
devices (3160).
* revert the new RBD allocation model because it introduced
a bug when running on weak VM setups.
* new device IDs
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
- Some dead defines dropped from the Samsung driver, was
targeted for -rc2 but got delayed
- Drop the strict mode from abx500, this was too strict
- Fix the R-Car sparse IRQs code to work as intended
- Fix the IRQ code for the pinctrl-single GPIO backend to not
enforce threaded IRQs
- Clear the latched events/IRQs for the Broadcom BCM2835
driver
- Fix up debugfs for the Freescale imx1 driver
- Fix a typo bug in the Schmitt Trigger setup in the LPC18xx
driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVrpAVAAoJEEEQszewGV1zeq8P/1hIdJfHYpVb5whr4Cxq2JFh
RHKFCBGI75JDj+K7dBjJkflBxnb158rFA7QxEumEFp2VnWFUzlFJeirGDM9KArXO
Wxsp+Lm9oO8U7T1dUXhsEZJTmVNXSiNcYbuaYOkxtuVn4YlVSS/XB3T8dcXPzKRG
3BHuKnOA5qpcvM9FaA1O1UiPwR/wc/SrtX38+c1Wt0dXJO+Tgj9PtiiK6iUQHskZ
rbsxXZEBTP2mcmBBXNtMXbAh9qnL88uG44zSEv1nTDr/jHVYftIVnTdQ07ICT3S9
mCKEloeZuvHPIkttZ9Ddlj5Jf5PbaqvJllSHhE9FPGEjkOgAtfNdf0zN+Zbqhj0F
aZAHtknYRsOXFDKAHJckUvXlumFrOSd/8vDIeaVwC807Lz190syBdgUbKVBtzZYf
r7+HC1y3XIyLk2M2ZiQLwaYJPr5DJqxNgxMm7Wg/E0mmwScPhvMhrYKNJQvSu2f2
hE/l0XigFxaY7JYAj49ltjaCOKXy02IMGTcT7MAYS9mSWeI8XFI+xPN2ZjiUkQLS
4nLG4oC9FfCndcAEYf4f/86L9F1k+5ysH+DsEbkB6aCjz1D3Lijb+IzoRJTH9CE9
jRyQbhtaC3kPJb7Ucsr4RBVCLOevu8E6xiBp0mdeeSc9a2mHZcrE1IVTU033oNOp
GDhPSA4vZApj0YJqZdTw
=pDEn
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are some overly ripe pin control fixes for the v4.2 series.
They got delayed because of various crap commits and having to clean
and rinse the patch stack a few times. Now they are however looking
good.
- some dead defines dropped from the Samsung driver, was targeted for
-rc2 but got delayed
- drop the strict mode from abx500, this was too strict
- fix the R-Car sparse IRQs code to work as intended
- fix the IRQ code for the pinctrl-single GPIO backend to not enforce
threaded IRQs
- clear the latched events/IRQs for the Broadcom BCM2835 driver
- fix up debugfs for the Freescale imx1 driver
- fix a typo bug in the Schmitt Trigger setup in the LPC18xx driver"
* tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: lpc18xx: fix schmitt trigger setup
Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback
pinctrl: bcm2835: Clear the event latch register when disabling interrupts
pinctrl: single: ensure pcs irq will not be forced threaded
sh-pfc: fix sparse GPIOs for R-Car SoCs
pinctrl: abx500: remove strict mode
pinctrl: samsung: Remove old unused defines
Pull UDF fix from Jan Kara:
"A fix for UDF corruption when certain disk-format feature is enabled"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
udf: Don't corrupt unalloc spacetable when writing it
function __get_dynamic_array_len() is broken. This only changes the
sample code, and I'm pushing this now instead of later because I don't
want others using the broken code as an example when using it for real.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVrpUnAAoJEEjnJuOKh9ld9TgIAM9lgZ9KsAcfWaYHotr6hd7r
cbpAN5L30H5iuwC6rN+gWe4roiIn9csIgR+LHcloBrjmRujQXY4FegeuMCwNZiQO
+J6SXuGxweZ+9kloMSw3RvQw8rp1hIIUwbvkybHNbFJq/w4m4nOraEhrVxxELCGd
iNoOFULVjEUyHoHtttsHzaSnxl3p2TXjHxk4RlZUL3kcxlbmeG2zsQhZF8F0Gw9/
/Q/fMzMGctl8Xj9SWwy6FIyF9DkqXDhSR0adzw/Hd03n1pMj9+YtBKNtnRAbt42E
V+y9hjaiulUuWD7U7q1FVQp1w3ksCX8E3fNooVKeUjA2Zkrbu1EYqpskwXpAtiw=
=Z2MY
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.2-rc2-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing sample code fix from Steven Rostedt:
"He Kuang noticed that the sample code using the trace_event helper
function __get_dynamic_array_len() is broken.
This only changes the sample code, and I'm pushing this now instead of
later because I don't want others using the broken code as an example
when using it for real"
* tag 'trace-v4.2-rc2-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix sample output of dynamic arrays
From Krzysztof Kozlowski:
1. Fix exynos3250 MIPI DSI display and MIPI CSIS-2 camera sensorx
after adding support for PMU regmap in exynos-video-mipi driver
(issue introduced in v4.0).
2. Bring back cpufreq for exynos4210 after incomplete switch to
cpufreq-dt driver in 4.2 merge window. The necessary DT changes
for exynos4210 cpufreq was not applied to the same tree as rest
of patchset because of multiple conflicts between clk and arm-soc
trees. Unfortunately without the change the exynos4210 boards
loose cpufreq feature.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJVrb2WAAoJEA0Cl+kVi2xq8JQQAKa3/4qF0blDS3WuZ37lpQsH
0cZpNqkcSbEmz8BtPrmFpxazPk0n3TuoL4nB0G/BqYtDyoX1LjJl2Da0vKFCYWGr
dlz+l5XuAElukpjqeb5P/luJahYHhpVJh3io9muigptaYPLtrfQEk4Fd2X9+lH+N
xJafP0lJAbN5PKD9rCXFdOJh2sU5UftUPbHhLrvFrkWoAsJ5xFPQy/HvXUr5v053
zqf6aGEHcV5L2W4NzNXmU5PBgDRx3sWNXrn0U+T3ZmHDpSXXweZNjBx02S7f0zcb
LKRECdzaXGOpCWqSI2JGkG6gBotL+ueCDttAY4LEA/jt0ppRjGcoXgl9Q6ADzBtc
arSWRGmZ76/ZHJsDLVbNU373gFJgFMx45qqGDaBs8MWTmbeOaqlBt9n0gFNX0aPC
QA1uoar6noqXRck/3BKUP5ksrzKs89jWBcDHpkwgAUX72Y6X3SyqRGsb2D/AOnnh
j8AwZ1JTLn1P2wrOwjeuRNCtWYtaUGcVqtukhuEcuq9bJJdvjjMRQae+9mKc6Tlv
HwSdL6NUmbBMQ+YaTz3aGJyozfZamZTAPoRV9WhwCseW2UmO8Izg3ffWBI6/3lKR
MJ+wrbkEe9N67XalVQB3i2UZ78GmWHE5LaUzZi2vfL2Q/cR4Q1aKZX3MxL+XsmSF
jzgwSCEnkDeh4O/L5vHE
=2MmH
-----END PGP SIGNATURE-----
Merge tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
Merge "Samsung fixes for v4.2" from Kukjin Kim:
From Krzysztof Kozlowski:
1. Fix exynos3250 MIPI DSI display and MIPI CSIS-2 camera sensorx
after adding support for PMU regmap in exynos-video-mipi driver
(issue introduced in v4.0).
2. Bring back cpufreq for exynos4210 after incomplete switch to
cpufreq-dt driver in 4.2 merge window. The necessary DT changes
for exynos4210 cpufreq was not applied to the same tree as rest
of patchset because of multiple conflicts between clk and arm-soc
trees. Unfortunately without the change the exynos4210 boards
loose cpufreq feature.
* tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: dts: add CPU OPP and regulator supply property for exynos4210
ARM: dts: Update video-phy node with syscon phandle for exynos3250
Signed-off-by: Olof Johansson <olof@lixom.net>
With commit c03abd8463 ("net: ethernet: cpsw: don't requests IRQs
we don't use") common isr and napi are separated into separate tx isr
and rx isr/napi, but still in rx napi tx events are handled. So removing
the tx event handling in rx napi.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When ip_frag_queue() computes positions, it assumes that the passed
sk_buff does not contain L2 headers.
However, when PACKET_FANOUT_FLAG_DEFRAG is used, IP reassembly
functions can be called on outgoing packets that contain L2 headers.
Also, IPv4 checksum is not corrected after reassembly.
Fixes: 7736d33f42 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee <edjee@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Jerry Chu <hkchu@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit fdb6eb0a12 ("ASoC: dapm: Modify widget stream name according to
prefix") fixed the case where a DAPM route between a DAI widget and a
DAC/ADC/AIF widget with a matching stream name was not created when the
DAPM context was using a prefix.
Unfortunately the patch introduced a few issues on its own like leaking the
dynamically allocated stream name memory and also not checking whether the
allocation succeeded in the first place.
It is also incomplete in that it still does not handle the case where
stream name of the widget is a substring of the stream name of the DAI,
which is explicitly allowed and works fine if no DAPM prefix is used.
Revert the commit and take a slightly different approach to solving the
issue. Instead of comparing the widget's stream name to the name of the DAI
widget compare it to the stream name of the DAI widget. The stream name of
the DAI widget is identical to the name of the DAI widget except that it
wont have the DAPM prefix added. So this approach behaves identical
regardless to whether the DAPM context uses a prefix or not.
We don't have to worry about potentially matching with a widget with the
same stream name, but from a different DAPM context with a different
prefix, since the code already makes sure that both the DAI widget and the
matched widget are from the same DAPM context.
Fixes: fdb6eb0a12 ("ASoC: dapm: Modify widget stream name according to prefix")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Since the hardware sometimes mysteriously totally flummoxes the 64bit
read of a 64bit register when read using a single instruction, split the
read into two instructions. Since the read here is of automatically
incrementing timestamp counters, we also have to be very careful in
order to make sure that it does not increment between the two
instructions.
However, since userspace tried to workaround this issue and so enshrined
this ABI for a broken hardware read and in the process neglected that
the read only fails in some environments, we have to introduce a new
uABI flag for userspace to request the 2x32 bit accurate read of the
timestamp.
v2: Fix alignment check and include details of the workaround for
userspace.
Reported-by: Karol Herbst <freedesktop@karolherbst.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317
Testcase: igt/gem_reg_read
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Tested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
