6 years agoLinux 3.2.71 v3.2.71
Ben Hutchings [Wed, 12 Aug 2015 14:33:24 +0000 (16:33 +0200)]
Linux 3.2.71

6 years agox86/xen: Probe target addresses in set_aliased_prot() before the hypercall
Andy Lutomirski [Thu, 30 Jul 2015 21:31:31 +0000 (14:31 -0700)]
x86/xen: Probe target addresses in set_aliased_prot() before the hypercall

commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.

The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables.  Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap

While we're at it, add comments to help explain what's going on.

This isn't a great long-term fix.  This code should probably be
changed to use something like set_memory_ro.

Signed-off-by: Andy Lutomirski <>
Cc: Andrew Cooper <>
Cc: Andy Lutomirski <>
Cc: Boris Ostrovsky <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: David Vrabel <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Jan Beulich <>
Cc: Konrad Rzeszutek Wilk <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Sasha Levin <>
Cc: Steven Rostedt <>
Cc: Thomas Gleixner <>
Cc: <>
Cc: xen-devel <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon/combios: add some validation of lvds values
Alex Deucher [Mon, 27 Jul 2015 23:24:31 +0000 (19:24 -0400)]
drm/radeon/combios: add some validation of lvds values

commit 0a90a0cff9f429f886f423967ae053150dce9259 upstream.

Fixes a broken hsync start value uncovered by:
(drm: Perform basic sanity checks on probed modes)

The driver handled the bad hsync start elsewhere, but
the above commit prevented it from getting added.


Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: add dB range mapping for some devices
Yao-Wen Mao [Wed, 29 Jul 2015 07:13:54 +0000 (15:13 +0800)]
ALSA: usb-audio: add dB range mapping for some devices

commit 2d1cb7f658fb9c3ba8f9dab8aca297d4dfdec835 upstream.

Add the correct dB ranges of Bose Companion 5 and Drangonfly DAC 1.2.

Signed-off-by: Yao-Wen Mao <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agovhost: actually track log eventfd file
Marc-André Lureau [Fri, 17 Jul 2015 13:32:03 +0000 (15:32 +0200)]
vhost: actually track log eventfd file

commit 7932c0bd7740f4cd2aa168d3ce0199e7af7d72d5 upstream.

While reviewing vhost log code, I found out that log_file is never
set. Note: I haven't tested the change (QEMU doesn't use LOG_FD yet).

Signed-off-by: Marc-André Lureau <>
Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: Ben Hutchings <>
6 years agoniu: don't count tx error twice in case of headroom realloc fails
Jiri Pirko [Thu, 23 Jul 2015 10:20:37 +0000 (12:20 +0200)]
niu: don't count tx error twice in case of headroom realloc fails

commit 42288830494cd51873ca745a7a229023df061226 upstream.

Fixes: a3138df9 ("[NIU]: Add Sun Neptune ethernet driver.")
Signed-off-by: Jiri Pirko <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoiscsi-target: Fix use-after-free during TPG session shutdown
Nicholas Bellinger [Wed, 22 Jul 2015 07:24:09 +0000 (00:24 -0700)]
iscsi-target: Fix use-after-free during TPG session shutdown

commit 417c20a9bdd1e876384127cf096d8ae8b559066c upstream.

This patch fixes a use-after-free bug in iscsit_release_sessions_for_tpg()
where se_portal_group->session_lock was incorrectly released/re-acquired
while walking the active se_portal_group->tpg_sess_list.

The can result in a NULL pointer dereference when iscsit_close_session()
shutdown happens in the normal path asynchronously to this code, causing
a bogus dereference of an already freed list entry to occur.

To address this bug, walk the session list checking for the same state
as before, but move entries to a local list to avoid dropping the lock
while walking the active list.

As before, signal using iscsi_session->session_restatement=1 for those
list entries to be released locally by iscsit_free_session() code.

Reported-by: Sunilkumar Nadumuttlu <>
Cc: Sunilkumar Nadumuttlu <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
6 years agomd/raid1: fix test for 'was read error from last working device'.
NeilBrown [Thu, 23 Jul 2015 23:22:16 +0000 (09:22 +1000)]
md/raid1: fix test for 'was read error from last working device'.

commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream.

When we get a read error from the last working device, we don't
try to repair it, and don't fail the device.  We simple report a
read error to the caller.

However the current test for 'is this the last working device' is
When there is only one fully working device, it assumes that a
non-faulty device is that device.  However a spare which is rebuilding
would be non-faulty but so not the only working device.

So change the test from "!Faulty" to "In_sync".  If ->degraded says
there is only one fully working device and this device is in_sync,
this must be the one.

This bug has existed since we allowed read_balance to read from
a recovering spare in v3.0

Reported-and-tested-by: Alexander Lyakas <>
Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: usbtouchscreen - avoid unresponsive TSC-30 touch screen
Bernhard Bender [Thu, 23 Jul 2015 20:58:08 +0000 (13:58 -0700)]
Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen

commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream.

This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30
touch screen.  Due to a missing delay between the RESET and SET_RATE
commands, the touch screen may become unresponsive during system startup or
driver loading.

According to the DMC documentation, a delay is needed after the RESET
command to allow the chip to complete its internal initialization. As this
delay is not guaranteed, we had a system where the touch screen
occasionally did not send any touch data. There was no other indication of
the problem.

The patch fixes the problem by adding a 150ms delay between the RESET and
SET_RATE commands.

Suggested-by: Jakob Mustafa <>
Signed-off-by: Bernhard Bender <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agotile: use free_bootmem_late() for initrd
Chris Metcalf [Thu, 23 Jul 2015 18:11:09 +0000 (14:11 -0400)]
tile: use free_bootmem_late() for initrd

commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.

We were previously using free_bootmem() and just getting lucky
that nothing too bad happened.

Signed-off-by: Chris Metcalf <>
Signed-off-by: Ben Hutchings <>
6 years agousb-storage: ignore ZTE MF 823 card reader in mode 0x1225
Oliver Neukum [Mon, 6 Jul 2015 11:12:32 +0000 (13:12 +0200)]
usb-storage: ignore ZTE MF 823 card reader in mode 0x1225

commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream.

This device automatically switches itself to another mode (0x1405)
unless the specific access pattern of Windows is followed in its
initial mode. That makes a dirty unmount of the internal storage
devices inevitable if they are mounted. So the card reader of
such a device should be ignored, lest an unclean removal become

This replaces an earlier patch that ignored all LUNs of this device.
That patch was overly broad.

Signed-off-by: Oliver Neukum <>
Reviewed-by: Lars Melin <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: do not report PLC when link is in internal resume state
Zhuang Jin Can [Tue, 21 Jul 2015 14:20:31 +0000 (17:20 +0300)]
xhci: do not report PLC when link is in internal resume state

commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.

Port link change with port in resume state should not be
reported to usbcore, as this is an internal state to be
handled by xhci driver. Reporting PLC to usbcore may
cause usbcore clearing PLC first and port change event irq
won't be generated.

Signed-off-by: Zhuang Jin Can <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust indentation
 - s/raw_port_status/temp/]
Signed-off-by: Ben Hutchings <>
6 years agoxhci: report U3 when link is in resume state
Zhuang Jin Can [Tue, 21 Jul 2015 14:20:29 +0000 (17:20 +0300)]
xhci: report U3 when link is in resume state

commit 243292a2ad3dc365849b820a64868927168894ac upstream.

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.

Signed-off-by: Zhuang Jin Can <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Calculate old endpoints correctly on device reset
Brian Campbell [Tue, 21 Jul 2015 14:20:28 +0000 (17:20 +0300)]
xhci: Calculate old endpoints correctly on device reset

commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream.

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

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.

Signed-off-by: Brian Campbell <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agousb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
AMAN DEEP [Tue, 21 Jul 2015 14:20:27 +0000 (17:20 +0300)]
usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function

commit 3496810663922617d4b706ef2780c279252ddd6a upstream.

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] =
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

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] = NULL;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

Signed-off-by: Aman Deep <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agonetfilter: nf_conntrack: Support expectations in different zones
Joe Stringer [Wed, 22 Jul 2015 04:37:31 +0000 (21:37 -0700)]
netfilter: nf_conntrack: Support expectations in different zones

commit 4b31814d20cbe5cd4ccf18089751e77a04afe4f2 upstream.

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 <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
6 years agousb: dwc3: Reset the transfer resource index on SET_INTERFACE
John Youn [Mon, 17 Sep 2001 07:00:00 +0000 (00:00 -0700)]
usb: dwc3: Reset the transfer resource index on SET_INTERFACE

commit aebda618718157a69c0dc0adb978d69bc2b8723c upstream.

This fixes an issue introduced in commit b23c843992b6 (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

This problem became aparent after commit 76e838c9f776 (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 <>
Tested-by: Subbaraya Sundeep Bhatta <>
Fixes: b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Signed-off-by: John Youn <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: use dev_vdbg() instead of dwc3_trace()]
Signed-off-by: Ben Hutchings <>
6 years agoinet: frags: fix defragmented packet's IP header for af_packet
Edward Hyunkoo Jee [Tue, 21 Jul 2015 07:43:59 +0000 (09:43 +0200)]
inet: frags: fix defragmented packet's IP header for af_packet

commit 0848f6428ba3a2e42db124d41ac6f548655735bf upstream.

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: 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee <>
Signed-off-by: Eric Dumazet <>
Cc: Willem de Bruijn <>
Cc: Jerry Chu <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomac80211: clear subdir_stations when removing debugfs
Tom Hughes [Mon, 29 Jun 2015 18:41:49 +0000 (19:41 +0100)]
mac80211: clear subdir_stations when removing debugfs

commit 4479004e6409087d1b4986881dc98c6c15dffb28 upstream.

If we don't do this, and we then fail to recreate the debugfs
directory during a mode change, then we will fail later trying
to add stations to this now bogus directory:

BUG: unable to handle kernel NULL pointer dereference at 0000006c
IP: [<c0a92202>] mutex_lock+0x12/0x30
Call Trace:
[<c0678ab4>] start_creating+0x44/0xc0
[<c0679203>] debugfs_create_dir+0x13/0xf0
[<f8a938ae>] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]

Signed-off-by: Tom Hughes <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL
Michel Dänzer [Fri, 3 Jul 2015 01:02:27 +0000 (10:02 +0900)]
drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL

commit 233709d2cd6bbaaeda0aeb8d11f6ca7f98563b39 upstream.

This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.

Fixes panic on powering off R7xx GPUs.

Reviewed-by: Christian König <>
Signed-off-by: Michel Dänzer <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
6 years agodatagram: Factor out sk queue referencing
Pavel Emelyanov [Tue, 21 Feb 2012 07:30:33 +0000 (07:30 +0000)]
datagram: Factor out sk queue referencing

commit 4934b0329f7150dcb5f90506860e2db32274c755 upstream.

This makes lines shorter and simplifies further patching.

Signed-off-by: Pavel Emelyanov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Prerequisite of "net: Clone skb before setting peeked flag"]
Signed-off-by: Ben Hutchings <>
6 years agolibata: increase the timeout when setting transfer mode
Mikulas Patocka [Wed, 8 Jul 2015 17:06:12 +0000 (13:06 -0400)]
libata: increase the timeout when setting transfer mode

commit d531be2ca2f27cca5f041b6a140504999144a617 upstream.

I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
the command that sets transfer mode causes the disk to spin up. The
spin-up takes longer than the default 5s timeout, so the command fails and
timeout is reported.

Fix this by increasing the timeout to 15s, which is enough for the disk to
spin up.

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agolibata: force disable trim for SuperSSpeed S238
Arne Fitzenreiter [Wed, 15 Jul 2015 11:54:37 +0000 (13:54 +0200)]
libata: force disable trim for SuperSSpeed S238

commit cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc upstream.

This device loses blocks, often the partition table area, on trim.
Disable TRIM.

Signed-off-by: Arne Fitzenreiter <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agolibata: add ATA_HORKAGE_NOTRIM
Arne Fitzenreiter [Wed, 15 Jul 2015 11:54:36 +0000 (13:54 +0200)]

commit 71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.

Some devices lose data on TRIM whether queued or not.  This patch adds
a horkage to disable TRIM.

tj: Collapsed unnecessary if() nesting.

Signed-off-by: Arne Fitzenreiter <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to show_ata_dev_trim()]
Signed-off-by: Ben Hutchings <>
6 years agolibata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER
Aleksei Mamlin [Wed, 1 Jul 2015 10:48:30 +0000 (13:48 +0300)]
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER

commit 08c85d2a599d967ede38a847f5594447b6100642 upstream.

Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors:

[    3.788362] ata3.00: failed to enable AA (error_mask=0x1)
[    3.789243] ata3.00: failed to enable AA (error_mask=0x1)

Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.

tj: Collected FPDMA_AA entries and updated comment.

Signed-off-by: Aleksei Mamlin <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agoata: pmp: add quirk for Marvell 4140 SATA PMP
Lior Amsalem [Tue, 30 Jun 2015 14:09:49 +0000 (16:09 +0200)]
ata: pmp: add quirk for Marvell 4140 SATA PMP

commit 945b47441d83d2392ac9f984e0267ad521f24268 upstream.

This commit adds the necessary quirk to make the Marvell 4140 SATA PMP
work properly. This PMP doesn't like SRST on port number 4 (the host
port) so this commit marks this port as not supporting SRST.

Signed-off-by: Lior Amsalem <>
Reviewed-by: Nadav Haklai <>
Signed-off-by: Thomas Petazzoni <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agords: rds_ib_device.refcount overflow
Wengang Wang [Mon, 6 Jul 2015 06:35:11 +0000 (14:35 +0800)]
rds: rds_ib_device.refcount overflow

commit 4fabb59449aa44a585b3603ffdadd4c5f4d0c033 upstream.

Fixes: 3e0249f9c05c ("RDS/IB: add refcount tracking to struct rds_ib_device")

There lacks a dropping on rds_ib_device.refcount in case rds_ib_alloc_fmr
failed(mr pool running out). this lead to the refcount overflow.

A complain in line 117(see following) is seen. From vmcore:
s_ib_rdma_mr_pool_depleted is 2147485544 and rds_ibdev->refcount is -2147475448.
That is the evidence the mr pool is used up. so rds_ib_alloc_fmr is very likely
to return ERR_PTR(-EAGAIN).

115 void rds_ib_dev_put(struct rds_ib_device *rds_ibdev)
116 {
117         BUG_ON(atomic_read(&rds_ibdev->refcount) <= 0);
118         if (atomic_dec_and_test(&rds_ibdev->refcount))
119                 queue_work(rds_wq, &rds_ibdev->free_work);
120 }

fix is to drop refcount when rds_ib_alloc_fmr failed.

Signed-off-by: Wengang Wang <>
Reviewed-by: Haggai Eran <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix file corruption after cloning inline extents
Filipe Manana [Tue, 14 Jul 2015 15:09:39 +0000 (16:09 +0100)]
Btrfs: fix file corruption after cloning inline extents

commit ed958762644b404654a6f5d23e869f496fe127c6 upstream.

Using the clone ioctl (or extent_same ioctl, which calls the same extent
cloning function as well) we end up allowing copy an inline extent from
the source file into a non-zero offset of the destination file. This is
something not expected and that the btrfs code is not prepared to deal
with - all inline extents must be at a file offset equals to 0.

For example, the following excerpt of a test case for fstests triggers
a crash/BUG_ON() on a write operation after an inline extent is cloned
into a non-zero offset:

  _scratch_mkfs >>$seqres.full 2>&1

  # Create our test files. File foo has the same 2K of data at offset 4K
  # as file bar has at its offset 0.
  $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 4K" \
      -c "pwrite -S 0xbb 4k 2K" \
      -c "pwrite -S 0xcc 8K 4K" \
      $SCRATCH_MNT/foo | _filter_xfs_io

  # File bar consists of a single inline extent (2K size).
  $XFS_IO_PROG -f -s -c "pwrite -S 0xbb 0 2K" \
     $SCRATCH_MNT/bar | _filter_xfs_io

  # Now call the clone ioctl to clone the extent of file bar into file
  # foo at its offset 4K. This made file foo have an inline extent at
  # offset 4K, something which the btrfs code can not deal with in future
  # IO operations because all inline extents are supposed to start at an
  # offset of 0, resulting in all sorts of chaos.
  # So here we validate that clone ioctl returns an EOPNOTSUPP, which is
  # what it returns for other cases dealing with inlined extents.
  $CLONER_PROG -s 0 -d $((4 * 1024)) -l $((2 * 1024)) \

  # Because of the inline extent at offset 4K, the following write made
  # the kernel crash with a BUG_ON().
  $XFS_IO_PROG -c "pwrite -S 0xdd 6K 2K" $SCRATCH_MNT/foo | _filter_xfs_io


The stack trace of the BUG_ON() triggered by the last write is:

  [152154.035903] ------------[ cut here ]------------
  [152154.036424] kernel BUG at mm/page-writeback.c:2286!
  [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  [152154.036424] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop fuse parport_pc acpi_cpu$
  [152154.036424] CPU: 2 PID: 17873 Comm: xfs_io Tainted: G        W       4.1.0-rc6-btrfs-next-11+ #2
  [152154.036424] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
  [152154.036424] task: ffff880429f70990 ti: ffff880429efc000 task.ti: ffff880429efc000
  [152154.036424] RIP: 0010:[<ffffffff8111a9d5>]  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
  [152154.036424] RSP: 0018:ffff880429effc68  EFLAGS: 00010246
  [152154.036424] RAX: 0200000000000806 RBX: ffffea0006a6d8f0 RCX: 0000000000000001
  [152154.036424] RDX: 0000000000000000 RSI: ffffffff81155d1b RDI: ffffea0006a6d8f0
  [152154.036424] RBP: ffff880429effc78 R08: ffff8801ce389fe0 R09: 0000000000000001
  [152154.036424] R10: 0000000000002000 R11: ffffffffffffffff R12: ffff8800200dce68
  [152154.036424] R13: 0000000000000000 R14: ffff8800200dcc88 R15: ffff8803d5736d80
  [152154.036424] FS:  00007fbf119f6700(0000) GS:ffff88043d280000(0000) knlGS:0000000000000000
  [152154.036424] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [152154.036424] CR2: 0000000001bdc000 CR3: 00000003aa555000 CR4: 00000000000006e0
  [152154.036424] Stack:
  [152154.036424]  ffff8803d5736d80 0000000000000001 ffff880429effcd8 ffffffffa04e97c1
  [152154.036424]  ffff880429effd68 ffff880429effd60 0000000000000001 ffff8800200dc9c8
  [152154.036424]  0000000000000001 ffff8800200dcc88 0000000000000000 0000000000001000
  [152154.036424] Call Trace:
  [152154.036424]  [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
  [152154.036424]  [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
  [152154.036424]  [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
  [152154.036424]  [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
  [152154.036424]  [<ffffffff81165f89>] vfs_write+0xa0/0xe4
  [152154.036424]  [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
  [152154.036424]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
  [152154.036424] Code: 48 89 c7 e8 0f ff ff ff 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 ae ef 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 59 49 8b 3c 2$
  [152154.036424] RIP  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
  [152154.036424]  RSP <ffff880429effc68>
  [152154.242621] ---[ end trace e3d3376b23a57041 ]---

Fix this by returning the error EOPNOTSUPP if an attempt to copy an
inline extent into a non-zero offset happens, just like what is done for
other scenarios that would require copying/splitting inline extents,
which were introduced by the following commits:

   00fdf13a2e9f ("Btrfs: fix a crash of clone with inline extents's split")
   3f9e3df8da3c ("btrfs: replace error code from btrfs_drop_extents")

Signed-off-by: Filipe Manana <>
[bwh: Backported to 3.2: test new_key.offset as last_dest_end isn't defined
 in this function]
Signed-off-by: Ben Hutchings <>
6 years agos390/process: fix sfpc inline assembly
Heiko Carstens [Mon, 6 Jul 2015 13:02:37 +0000 (15:02 +0200)]
s390/process: fix sfpc inline assembly

commit e47994dd44bcb4a77b4152bd0eada585934703c0 upstream.

The sfpc inline assembly within execve_tail() may incorrectly set bits
28-31 of the sfpc instruction to a value which is not zero.
These bits however are currently unused and therefore should be zero
so we won't get surprised if these bits will be used in the future.

Therefore remove the second operand from the inline assembly.

Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years ago9p: don't leave a half-initialized inode sitting around
Al Viro [Sun, 12 Jul 2015 14:34:29 +0000 (10:34 -0400)]
9p: don't leave a half-initialized inode sitting around

commit 0a73d0a204a4a04a1e110539c5a524ae51f91d6d upstream.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agonet: call rcu_read_lock early in process_backlog
Julian Anastasov [Thu, 9 Jul 2015 06:59:10 +0000 (09:59 +0300)]
net: call rcu_read_lock early in process_backlog

commit 2c17d27c36dcce2b6bf689f41a46b9e909877c21 upstream.

Incoming packet should be either in backlog queue or
in RCU read-side section. Otherwise, the final sequence of
flush_backlog() and synchronize_net() may miss packets
that can run without device reference:

CPU 1                  CPU 2
                       skb->dev: no reference

on_each_cpu for
flush_backlog =>       IPI(hardirq): flush_backlog
                       - packet not found in backlog

                       CPU delayed ...
- no ongoing RCU
read-side sections

rcu_barrier: no
ongoing callbacks
                       - too late
free dev
                       process packet for freed dev

Fixes: 6e583ce5242f ("net: eliminate refcounting in backlog queue")
Cc: Eric W. Biederman <>
Cc: Stephen Hemminger <>
Signed-off-by: Julian Anastasov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust context
 - No need to rename the label in __netif_receive_skb()]
Signed-off-by: Ben Hutchings <>
6 years agonet: do not process device backlog during unregistration
Julian Anastasov [Thu, 9 Jul 2015 06:59:09 +0000 (09:59 +0300)]
net: do not process device backlog during unregistration

commit e9e4dd3267d0c5234c5c0f47440456b10875dec9 upstream.

commit 381c759d9916 ("ipv4: Avoid crashing in ip_error")
fixes a problem where processed packet comes from device
with destroyed inetdev (dev->ip_ptr). This is not expected
because inetdev_destroy is called in NETDEV_UNREGISTER
phase and packets should not be processed after
dev_close_many() and synchronize_net(). Above fix is still
required because inetdev_destroy can be called for other
reasons. But it shows the real problem: backlog can keep
packets for long time and they do not hold reference to
device. Such packets are then delivered to upper levels
at the same time when device is unregistered.
Calling flush_backlog after NETDEV_UNREGISTER_FINAL still
accounts all packets from backlog but before that some packets
continue to be delivered to upper levels long after the
synchronize_net call which is supposed to wait the last
ones. Also, as Eric pointed out, processed packets, mostly
from other devices, can continue to add new packets to backlog.

Fix the problem by moving flush_backlog early, after the
device driver is stopped and before the synchronize_net() call.
Then use netif_running check to make sure we do not add more
packets to backlog. We have to do it in enqueue_to_backlog
context when the local IRQ is disabled. As result, after the
flush_backlog and synchronize_net sequence all packets
should be accounted.

Thanks to Eric W. Biederman for the test script and his
valuable feedback!

Reported-by: Vittorio Gambaletta <>
Fixes: 6e583ce5242f ("net: eliminate refcounting in backlog queue")
Cc: Eric W. Biederman <>
Cc: Stephen Hemminger <>
Signed-off-by: Julian Anastasov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomm: avoid setting up anonymous pages into file mapping
Kirill A. Shutemov [Mon, 6 Jul 2015 20:18:37 +0000 (23:18 +0300)]
mm: avoid setting up anonymous pages into file mapping

commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream.

Reading page fault handler code I've noticed that under right
circumstances kernel would map anonymous pages into file mappings: if
the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
on ->mmap(), kernel would handle page fault to not populated pte with

Let's change page fault handler to use do_anonymous_page() only on
anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not

For file mappings without vm_ops->fault() or shred VMA without vm_ops,
page fault on pte_none() entry would lead to SIGBUS.

Signed-off-by: Kirill A. Shutemov <>
Acked-by: Oleg Nesterov <>
Cc: Andrew Morton <>
Cc: Willy Tarreau <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agortnetlink: verify IFLA_VF_INFO attributes before passing them to driver
Daniel Borkmann [Mon, 6 Jul 2015 22:07:52 +0000 (00:07 +0200)]
rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

commit 4f7d2cdfdde71ffe962399b7020c674050329423 upstream.

Jason Gunthorpe reported that since commit c02db8c6290b ("rtnetlink: make
SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
anymore with respect to their policy, that is, ifla_vfinfo_policy[].

Before, they were part of ifla_policy[], but they have been nested since
placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
which is another nested attribute for the actual VF attributes such as

Despite the policy being split out from ifla_policy[] in this commit,
it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
testing for struct nlattr, but it doesn't know about the data context and
their requirements.

Fix, on top of Jason's initial work, does 1) parsing of the attributes
with the right policy, and 2) using the resulting parsed attribute table
from 1) instead of the nla_for_each_nested() loop (just like we used to
do when still part of ifla_policy[]).

Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
Reported-by: Jason Gunthorpe <>
Cc: Chris Wright <>
Cc: Sucheta Chakraborty <>
Cc: Greg Rose <>
Cc: Jeff Kirsher <>
Cc: Rony Efraim <>
Cc: Vlad Zolotarov <>
Cc: Nicolas Dichtel <>
Cc: Thomas Graf <>
Signed-off-by: Jason Gunthorpe <>
Signed-off-by: Daniel Borkmann <>
Acked-by: Vlad Zolotarov <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop unsupported attributes
 - Use ndo_set_vf_tx_rate operation, not ndo_set_vf_rate]
Signed-off-by: Ben Hutchings <>
6 years agodrm: add a check for x/y in drm_mode_setcrtc
Zhao Junwang [Tue, 7 Jul 2015 09:08:35 +0000 (17:08 +0800)]
drm: add a check for x/y in drm_mode_setcrtc

commit 01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream.

legacy setcrtc ioctl does take a 32 bit value which might indeed

the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this

v2: -polish the annotation according to Daniel's comment

Cc: Daniel Vetter <>
Signed-off-by: Zhao Junwang <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
6 years agodrm: Check crtc x and y coordinates
Ville Syrjälä [Tue, 13 Mar 2012 10:35:41 +0000 (12:35 +0200)]
drm: Check crtc x and y coordinates

commit 1d97e9154821d52a5ebc226176d4839c7b86b116 upstream.

The crtc x/y panning coordinates are stored as signed integers
internally. The user provides them as unsigned, so we should check
that the user provided values actually fit in the internal datatypes.

Signed-off-by: Ville Syrjälä <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
6 years agos390/sclp: clear upper register halves in _sclp_print_early
Martin Schwidefsky [Mon, 6 Jul 2015 15:58:19 +0000 (17:58 +0200)]
s390/sclp: clear upper register halves in _sclp_print_early

commit f9c87a6f46d508eae0d9ae640be98d50f237f827 upstream.

If the kernel is compiled with gcc 5.1 and the XZ compression option
the decompress_kernel function calls _sclp_print_early in 64-bit mode
while the content of the upper register half of %r6 is non-zero.
This causes a specification exception on the servc instruction in

The _sclp_print_early function saves and restores the upper registers
halves but it fails to clear them for the 31-bit code of the mini sclp

Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Ben Hutchings <>
6 years agodm btree: silence lockdep lock inversion in dm_btree_del()
Joe Thornber [Fri, 3 Jul 2015 13:51:32 +0000 (14:51 +0100)]
dm btree: silence lockdep lock inversion in dm_btree_del()

commit 1c7518794a3647eb345d59ee52844e8a40405198 upstream.

Allocate memory using GFP_NOIO when deleting a btree.  dm_btree_del()
can be called via an ioctl and we don't want to recurse into the FS or
block layer.

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: cp210x: add ID for Aruba Networks controllers
Peter Sanford [Fri, 26 Jun 2015 00:40:05 +0000 (17:40 -0700)]
USB: cp210x: add ID for Aruba Networks controllers

commit f98a7aa81eeeadcad25665c3501c236d531d4382 upstream.

Add the USB serial console device ID for Aruba Networks 7xxx series
controllers which have a USB port for their serial console.

Signed-off-by: Peter Sanford <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agodm thin: allocate the cell_sort_array dynamically
Joe Thornber [Fri, 3 Jul 2015 09:22:42 +0000 (10:22 +0100)]
dm thin: allocate the cell_sort_array dynamically

commit a822c83e47d97cdef38c4352e1ef62d9f46cfe98 upstream.

Given the pool's cell_sort_array holds 8192 pointers it triggers an
order 5 allocation via kmalloc.  This order 5 allocation is prone to
failure as system memory gets more fragmented over time.

Fix this by allocating the cell_sort_array using vmalloc.

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
[bwh: Backported to 3.2: make a similar change in prison_{create,destroy}()]
Signed-off-by: Ben Hutchings <>
6 years agodm btree remove: fix bug in redistribute3
Dennis Yang [Fri, 26 Jun 2015 14:25:48 +0000 (15:25 +0100)]
dm btree remove: fix bug in redistribute3

commit 4c7e309340ff85072e96f529582d159002c36734 upstream.

redistribute3() shares entries out across 3 nodes.  Some entries were
being moved the wrong way, breaking the ordering.  This manifested as a
BUG() in dm-btree-remove.c:shift() when entries were removed from the

For additional context see:

Signed-off-by: Dennis Yang <>
Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: replace open coded nofail allocation in ext4_free_blocks()
Michal Hocko [Sun, 5 Jul 2015 16:33:44 +0000 (12:33 -0400)]
ext4: replace open coded nofail allocation in ext4_free_blocks()

commit 7444a072c387a93ebee7066e8aee776954ab0e41 upstream.

ext4_free_blocks is looping around the allocation request and mimics
__GFP_NOFAIL behavior without any allocation fallback strategy. Let's
remove the open coded loop and replace it with __GFP_NOFAIL. Without the
flag the allocator has no way to find out never-fail requirement and
cannot help in any way.

Signed-off-by: Michal Hocko <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/ext4_free_data_cachep/ext4_free_ext_cachep/]
Signed-off-by: Ben Hutchings <>
6 years ago9p: forgetting to cancel request on interrupted zero-copy RPC
Al Viro [Sat, 4 Jul 2015 20:04:19 +0000 (16:04 -0400)]
9p: forgetting to cancel request on interrupted zero-copy RPC

commit a84b69cb6e0a41e86bc593904faa6def3b957343 upstream.

If we'd already sent a request and decide to abort it, we *must*
issue TFLUSH properly and not just blindly reuse the tag, or
we'll get seriously screwed when response eventually arrives
and we confuse it for response to later request that had reused
the same tag.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
6 years agoKVM: x86: properly restore LVT0
Radim Krčmář [Tue, 30 Jun 2015 20:19:17 +0000 (22:19 +0200)]
KVM: x86: properly restore LVT0

commit db1385624c686fe99fe2d1b61a36e1537b915d08 upstream.

Legacy NMI watchdog didn't work after migration/resume, because
vapics_in_nmi_mode was left at 0.

Signed-off-by: Radim Krčmář <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/kvm_apic_get_reg/apic_get_reg/]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: x86: make vapics_in_nmi_mode atomic
Radim Krčmář [Wed, 1 Jul 2015 13:31:49 +0000 (15:31 +0200)]
KVM: x86: make vapics_in_nmi_mode atomic

commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.

Writes were a bit racy, but hard to turn into a bug at the same time.
(Particularly because modern Linux doesn't use this feature anymore.)

Signed-off-by: Radim Krčmář <>
[Actually the next patch makes it much, much easier to trigger the race
 so I'm including this one for stable@ as well. - Paolo]
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonetfilter: bridge: don't leak skb in error paths
Florian Westphal [Tue, 30 Jun 2015 20:27:51 +0000 (22:27 +0200)]
netfilter: bridge: don't leak skb in error paths

commit dd302b59bde0149c20df7278c0d36c765e66afbd upstream.

br_nf_dev_queue_xmit must free skb in its error path.
NF_DROP is misleading -- its an okfn, not a netfilter hook.

Fixes: 462fb2af9788a ("bridge : Sanitize skb before it enters the IP stack")
Fixes: efb6de9b4ba00 ("netfilter: bridge: forward IPv6 fragmented packets")
Signed-off-by: Florian Westphal <>
Signed-off-by: Pablo Neira Ayuso <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Drop IPv6 changes]
Signed-off-by: Ben Hutchings <>
6 years agoext4: avoid deadlocks in the writeback path by using sb_getblk_gfp
Nikolay Borisov [Thu, 2 Jul 2015 05:34:07 +0000 (01:34 -0400)]
ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp

commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 upstream.

Switch ext4 to using sb_getblk_gfp with GFP_NOFS added to fix possible
deadlocks in the page writeback path.

Signed-off-by: Nikolay Borisov <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agobufferhead: Add _gfp version for sb_getblk()
Nikolay Borisov [Thu, 2 Jul 2015 05:32:44 +0000 (01:32 -0400)]
bufferhead: Add _gfp version for sb_getblk()

commit bd7ade3cd9b0850264306f5c2b79024a417b6396 upstream.

sb_getblk() is used during ext4 (and possibly other FSes) writeback
paths. Sometimes such path require allocating memory and guaranteeing
that such allocation won't block. Currently, however, there is no way
to provide user flags for sb_getblk which could lead to deadlocks.

This patch implements a sb_getblk_gfp with the only difference it can
accept user-provided GFP flags.

Signed-off-by: Nikolay Borisov <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agofs/buffer.c: support buffer cache allocations with gfp modifiers
Gioh Kim [Fri, 5 Sep 2014 02:04:42 +0000 (22:04 -0400)]
fs/buffer.c: support buffer cache allocations with gfp modifiers

commit 3b5e6454aaf6b4439b19400d8365e2ec2d24e411 upstream.

A buffer cache is allocated from movable area because it is referred
for a while and released soon.  But some filesystems are taking buffer
cache for a long time and it can disturb page migration.

New APIs are introduced to allocate buffer cache with user specific
flag.  *_gfp APIs are for user want to set page allocation flag for
page cache allocation.  And *_unmovable APIs are for the user wants to
allocate page cache from non-movable area.

Signed-off-by: Gioh Kim <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Jan Kara <>
[bwh: Prerequisite for "bufferhead: Add _gfp version for sb_getblk()".
 Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoACPICA: Tables: Fix an issue that FACS initialization is performed twice
Lv Zheng [Wed, 1 Jul 2015 06:43:26 +0000 (14:43 +0800)]
ACPICA: Tables: Fix an issue that FACS initialization is performed twice

commit c04be18448355441a0c424362df65b6422e27bda upstream.

ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658

This patch adds a new FACS initialization flag for acpi_tb_initialize().
acpi_enable_subsystem() might be invoked several times in OS bootup process,
and we don't want FACS initialization to be invoked twice. Lv Zheng.

Signed-off-by: Lv Zheng <>
Signed-off-by: Bob Moore <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4
Dominic Sacré [Tue, 30 Jun 2015 15:41:33 +0000 (17:41 +0200)]
ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4

commit 0689a86ae814f39af94a9736a0a5426dd82eb107 upstream.

The Steinberg MI2 and MI4 interfaces are compatible with the USB class
audio spec, but the MIDI part of the devices is reported as a vendor
specific interface.

This patch adds entries to quirks-table.h to recognize the MIDI
endpoints. Audio functionality was already working and is unaffected by
this change.

Signed-off-by: Dominic Sacré <>
Signed-off-by: Albert Huitsing <>
Acked-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agofuse: initialize fc->release before calling it
Miklos Szeredi [Wed, 1 Jul 2015 14:25:55 +0000 (16:25 +0200)]
fuse: initialize fc->release before calling it

commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream.

fc->release is called from fuse_conn_put() which was used in the error
cleanup before fc->release was initialized.

[Jeremiah Mahler <>: assign fc->release after calling
fuse_conn_init(fc) instead of before.]

Signed-off-by: Miklos Szeredi <>
Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()")
Signed-off-by: Ben Hutchings <>
6 years agocrush: fix a bug in tree bucket decode
Ilya Dryomov [Mon, 29 Jun 2015 16:30:23 +0000 (19:30 +0300)]
crush: fix a bug in tree bucket decode

commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream.

struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe()
should be used.  -Wconversion catches this, but I guess it went
unnoticed in all the noise it spews.  The actual problem (at least for
common crushmaps) isn't the u32 -> u8 truncation though - it's the
advancement by 4 bytes instead of 1 in the crushmap buffer.


Signed-off-by: Ilya Dryomov <>
Reviewed-by: Josh Durgin <>
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix race between caching kthread and returning inode to inode cache
Filipe Manana [Sat, 13 Jun 2015 05:52:57 +0000 (06:52 +0100)]
Btrfs: fix race between caching kthread and returning inode to inode cache

commit ae9d8f17118551bedd797406a6768b87c2146234 upstream.

While the inode cache caching kthread is calling btrfs_unpin_free_ino(),
we could have a concurrent call to btrfs_return_ino() that adds a new
entry to the root's free space cache of pinned inodes. This concurrent
call does not acquire the fs_info->commit_root_sem before adding a new
entry if the caching state is BTRFS_CACHE_FINISHED, which is a problem
because the caching kthread calls btrfs_unpin_free_ino() after setting
the caching state to BTRFS_CACHE_FINISHED and therefore races with
the task calling btrfs_return_ino(), which is adding a new entry, while
the former (caching kthread) is navigating the cache's rbtree, removing
and freeing nodes from the cache's rbtree without acquiring the spinlock
that protects the rbtree.

This race resulted in memory corruption due to double free of struct
btrfs_free_space objects because both tasks can end up doing freeing the
same objects. Note that adding a new entry can result in merging it with
other entries in the cache, in which case those entries are freed.
This is particularly important as btrfs_free_space structures are also
used for the block group free space caches.

This memory corruption can be detected by a debugging kernel, which
reports it with the following trace:

[132408.501148] slab error in verify_redzone_free(): cache `btrfs_free_space': double free detected
[132408.505075] CPU: 15 PID: 12248 Comm: btrfs-ino-cache Tainted: G        W       4.1.0-rc5-btrfs-next-10+ #1
[132408.505075] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 04/01/2014
[132408.505075]  ffff880023e7d320 ffff880163d73cd8 ffffffff8145eec7 ffffffff81095dce
[132408.505075]  ffff880009735d40 ffff880163d73ce8 ffffffff81154e1e ffff880163d73d68
[132408.505075]  ffffffff81155733 ffffffffa054a95a ffff8801b6099f00 ffffffffa0505b5f
[132408.505075] Call Trace:
[132408.505075]  [<ffffffff8145eec7>] dump_stack+0x4f/0x7b
[132408.505075]  [<ffffffff81095dce>] ? console_unlock+0x356/0x3a2
[132408.505075]  [<ffffffff81154e1e>] __slab_error.isra.28+0x25/0x36
[132408.505075]  [<ffffffff81155733>] __cache_free+0xe2/0x4b6
[132408.505075]  [<ffffffffa054a95a>] ? __btrfs_add_free_space+0x2f0/0x343 [btrfs]
[132408.505075]  [<ffffffffa0505b5f>] ? btrfs_unpin_free_ino+0x8e/0x99 [btrfs]
[132408.505075]  [<ffffffff810f3b30>] ? time_hardirqs_off+0x15/0x28
[132408.505075]  [<ffffffff81084d42>] ? trace_hardirqs_off+0xd/0xf
[132408.505075]  [<ffffffff811563a1>] ? kfree+0xb6/0x14e
[132408.505075]  [<ffffffff811563d0>] kfree+0xe5/0x14e
[132408.505075]  [<ffffffffa0505b5f>] btrfs_unpin_free_ino+0x8e/0x99 [btrfs]
[132408.505075]  [<ffffffffa0505e08>] caching_kthread+0x29e/0x2d9 [btrfs]
[132408.505075]  [<ffffffffa0505b6a>] ? btrfs_unpin_free_ino+0x99/0x99 [btrfs]
[132408.505075]  [<ffffffff8106698f>] kthread+0xef/0xf7
[132408.505075]  [<ffffffff810f3b08>] ? time_hardirqs_on+0x15/0x28
[132408.505075]  [<ffffffff810668a0>] ? __kthread_parkme+0xad/0xad
[132408.505075]  [<ffffffff814653d2>] ret_from_fork+0x42/0x70
[132408.505075]  [<ffffffff810668a0>] ? __kthread_parkme+0xad/0xad
[132408.505075] ffff880023e7d320: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b.
[132409.501654] slab: double free detected in cache 'btrfs_free_space', objp ffff880023e7d320
[132409.503355] ------------[ cut here ]------------
[132409.504241] kernel BUG at mm/slab.c:2571!

Therefore fix this by having btrfs_unpin_free_ino() acquire the lock
that protects the rbtree while doing the searches and removing entries.

Fixes: 1c70d8fb4dfa ("Btrfs: fix inode caching vs tree log")
Signed-off-by: Filipe Manana <>
Signed-off-by: Chris Mason <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: use kmem_cache_free when freeing entry in inode cache
Filipe Manana [Sat, 13 Jun 2015 05:52:56 +0000 (06:52 +0100)]
Btrfs: use kmem_cache_free when freeing entry in inode cache

commit c3f4a1685bb87e59c886ee68f7967eae07d4dffa upstream.

The free space entries are allocated using kmem_cache_zalloc(),
through __btrfs_add_free_space(), therefore we should use
kmem_cache_free() and not kfree() to avoid any confusion and
any potential problem. Looking at the kfree() definition at
mm/slab.c it has the following comment:

   * (...)
   * Don't free memory not originally allocated by kmalloc()
   * or you will run into trouble.

So better be safe and use kmem_cache_free().

Signed-off-by: Filipe Manana <>
Reviewed-by: David Sterba <>
Signed-off-by: Chris Mason <>
Signed-off-by: Ben Hutchings <>
6 years agoagp/intel: Fix typo in needs_ilk_vtd_wa()
Chris Wilson [Sun, 28 Jun 2015 13:18:16 +0000 (14:18 +0100)]
agp/intel: Fix typo in needs_ilk_vtd_wa()

commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson <>
Date:   Wed Feb 13 09:31:53 2013 +0000

    drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan <>
Signed-off-by: Chris Wilson <>
Cc: Daniel Vetter <>
Reviewed-by: Daniel Vetter <>
Signed-off-by: Jani Nikula <>
Signed-off-by: Ben Hutchings <>
6 years ago__bitmap_parselist: fix bug in empty string handling
Chris Metcalf [Thu, 25 Jun 2015 22:02:08 +0000 (15:02 -0700)]
__bitmap_parselist: fix bug in empty string handling

commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream.

bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in
the mask.  The same bug is visible in cpumask_parselist() since it is
layered on top of the bitmask code, e.g.  if you boot with "isolcpus=",
you will actually end up with cpu zero isolated.

The bug was introduced in commit 4b060420a596 ("bitmap, irq: add
smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
generalized to support userspace as well as kernelspace.

Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
Signed-off-by: Chris Metcalf <>
Cc: Rasmus Villemoes <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agotracing/filter: Do not allow infix to exceed end of string
Steven Rostedt (Red Hat) [Thu, 25 Jun 2015 22:10:09 +0000 (18:10 -0400)]
tracing/filter: Do not allow infix to exceed end of string

commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream.

While debugging a WARN_ON() for filtering, I found that it is possible
for the filter string to be referenced after its end. With the filter:

 # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter

The filter_parse() function can call infix_get_op() which calls
infix_advance() that updates the infix filter pointers for the cnt
and tail without checking if the filter is already at the end, which
will put the cnt to zero and the tail beyond the end. The loop then calls
infix_next() that has

return ps->infix.string[ps->infix.tail++];

The cnt will now be below zero, and the tail that is returned is
already passed the end of the filter string. So far the allocation
of the filter string usually has some buffer that is zeroed out, but
if the filter string is of the exact size of the allocated buffer
there's no guarantee that the charater after the nul terminating
character will be zero.

Luckily, only root can write to the filter.

Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agotracing/filter: Do not WARN on operand count going below zero
Steven Rostedt (Red Hat) [Thu, 25 Jun 2015 22:02:29 +0000 (18:02 -0400)]
tracing/filter: Do not WARN on operand count going below zero

commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.

When testing the fix for the trace filter, I could not come up with
a scenario where the operand count goes below zero, so I added a
WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
that it can happen (although the filter would be wrong).

 # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter

That is, a single operation without any operands will hit the path
where the WARN_ON_ONCE() can trigger. Although this is harmless,
and the filter is reported as a error. But instead of spitting out
a warning to the kernel dmesg, just fail nicely and report it via
the proper channels.

Reported-by: Vince Weaver <>
Reported-by: Sasha Levin <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agodell-laptop: Fix allocating & freeing SMI buffer page
Pali Rohár [Tue, 23 Jun 2015 08:11:19 +0000 (10:11 +0200)]
dell-laptop: Fix allocating & freeing SMI buffer page

commit b8830a4e71b15d0364ac8e6c55301eea73f211da upstream.

This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.

This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of sequential call of functions
alloc_page() and page_address().

Signed-off-by: Pali Rohár <>
Acked-by: Michal Hocko <>
Signed-off-by: Darren Hart <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomm: kmemleak: allow safe memory scanning during kmemleak disabling
Catalin Marinas [Wed, 24 Jun 2015 23:58:26 +0000 (16:58 -0700)]
mm: kmemleak: allow safe memory scanning during kmemleak disabling

commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.

The kmemleak scanning thread can run for minutes.  Callbacks like
kmemleak_free() are allowed during this time, the race being taken care
of by the object->lock spinlock.  Such lock also prevents a memory block
from being freed or unmapped while it is being scanned by blocking the
kmemleak_free() -> ...  -> __delete_object() function until the lock is
released in scan_object().

When a kmemleak error occurs (e.g.  it fails to allocate its metadata),
kmemleak_enabled is set and __delete_object() is no longer called on
freed objects.  If kmemleak_scan is running at the same time,
kmemleak_free() no longer waits for the object scanning to complete,
allowing the corresponding memory block to be freed or unmapped (in the
case of vfree()).  This leads to kmemleak_scan potentially triggering a
page fault.

This patch separates the kmemleak_free() enabling/disabling from the
overall kmemleak_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed.  The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.

Signed-off-by: Catalin Marinas <>
Reported-by: Vignesh Radhakrishnan <>
Tested-by: Vignesh Radhakrishnan <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes to kmemleak_free_percpu()]
Signed-off-by: Ben Hutchings <>
6 years agostmmac: troubleshoot unexpected bits in des0 & des1
Alexey Brodkin [Wed, 24 Jun 2015 08:47:41 +0000 (11:47 +0300)]
stmmac: troubleshoot unexpected bits in des0 & des1

commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
     dma_alloc_coherent() might not be zeroed and so
     it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
     controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
     dma_alloc_coherent() to make sure allocated memory is
     zeroed. That shouldn't affect performance because
     this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
     of all buffer descriptors during initialization of
     DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin <>
Cc: Giuseppe Cavallaro <>
Cc: David Miller <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Normal and extended descriptors are allocated in the same place here]
Signed-off-by: Ben Hutchings <>
Acked-by: Alexey Brodkin <>
6 years agofs: Fix S_NOSEC handling
Jan Kara [Thu, 21 May 2015 14:05:52 +0000 (16:05 +0200)]
fs: Fix S_NOSEC handling

commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.

file_remove_suid() could mistakenly set S_NOSEC inode bit when root was
modifying the file. As a result following writes to the file by ordinary
user would avoid clearing suid or sgid bits.

Fix the bug by checking actual mode bits before setting S_NOSEC.

Signed-off-by: Jan Kara <>
Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agobridge: multicast: restore router configuration on port link down/up
Satish Ashok [Fri, 19 Jun 2015 08:22:57 +0000 (01:22 -0700)]
bridge: multicast: restore router configuration on port link down/up

commit 754bc547f0a79f7568b5b81c7fc0a8d044a6571a upstream.

When a port goes through a link down/up the multicast router configuration
is not restored.

Signed-off-by: Satish Ashok <>
Signed-off-by: Nikolay Aleksandrov <>
Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries")
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoNET: ROSE: Don't dereference NULL neighbour pointer.
Ralf Baechle [Thu, 18 Jun 2015 22:46:53 +0000 (00:46 +0200)]
NET: ROSE: Don't dereference NULL neighbour pointer.

commit d496f7842aada20c61e6044b3395383fa972872c upstream.

A ROSE socket doesn't necessarily always have a neighbour pointer so check
if the neighbour pointer is valid before dereferencing it.

Signed-off-by: Ralf Baechle <>
Tested-by: Bernard Pidoux <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agowatchdog: omap: assert the counter being stopped before reprogramming
Uwe Kleine-König [Wed, 29 Apr 2015 18:38:46 +0000 (20:38 +0200)]
watchdog: omap: assert the counter being stopped before reprogramming

commit 530c11d432727c697629ad5f9d00ee8e2864d453 upstream.

The omap watchdog has the annoying behaviour that writes to most
registers don't have any effect when the watchdog is already running.
Quoting the AM335x reference manual:

To modify the timer counter value (the WDT_WCRR register),
prescaler ratio (the WDT_WCLR[4:2] PTV bit field), delay
configuration value (the WDT_WDLY[31:0] DLY_VALUE bit field), or
the load value (the WDT_WLDR[31:0] TIMER_LOAD bit field), the
watchdog timer must be disabled by using the start/stop sequence
(the WDT_WSPR register).

Currently the timer is stopped in the .probe callback but still there
are possibilities that yield to a situation where omap_wdt_start is
entered with the timer running (e.g. when /dev/watchdog is closed
without stopping and then reopened). In such a case programming the
timeout silently fails!

To circumvent this stop the timer before reprogramming.

Assuming one of the first things the watchdog user does is setting the
timeout explicitly nothing too bad should happen because this explicit
setting works fine.

Fixes: 7768a13c252a ("[PATCH] OMAP: Add Watchdog driver support")
Signed-off-by: Uwe Kleine-König <>
Reviewed-by: Guenter Roeck <>
Signed-off-by: Wim Van Sebroeck <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: don't retry file block mapping on bigalloc fs with non-extent file
Darrick J. Wong [Mon, 22 Jun 2015 01:10:51 +0000 (21:10 -0400)]
ext4: don't retry file block mapping on bigalloc fs with non-extent file

commit 292db1bc6c105d86111e858859456bcb11f90f91 upstream.

ext4 isn't willing to map clusters to a non-extent file.  Don't signal
this with an out of space error, since the FS will retry the
allocation (which didn't fail) forever.  Instead, return EUCLEAN so
that the operation will fail immediately all the way back to userspace.

(The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.)

Signed-off-by: Darrick J. Wong <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoiio: DAC: ad5624r_spi: fix bit shift of output data value
JM Friedt [Fri, 19 Jun 2015 12:48:06 +0000 (14:48 +0200)]
iio: DAC: ad5624r_spi: fix bit shift of output data value

commit adfa969850ae93beca57f7527f0e4dc10cbe1309 upstream.

The value sent on the SPI bus is shifted by an erroneous number of bits.
The shift value was already computed in the iio_chan_spec structure and
hence subtracting this argument to 16 yields an erroneous data position
in the SPI stream.

Signed-off-by: JM Friedt <>
Acked-by: Lars-Peter Clausen <>
Signed-off-by: Jonathan Cameron <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoext4: call sync_blockdev() before invalidate_bdev() in put_super()
Theodore Ts'o [Sun, 21 Jun 2015 02:50:33 +0000 (22:50 -0400)]
ext4: call sync_blockdev() before invalidate_bdev() in put_super()

commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.

Normally all of the buffers will have been forced out to disk before
we call invalidate_bdev(), but there will be some cases, where a file
system operation was aborted due to an ext4_error(), where there may
still be some dirty buffers in the buffer cache for the device.  So
try to force them out to memory before calling invalidate_bdev().

This fixes a warning triggered by generic/081:

WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f()

Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agoBluetooth: ath3k: add support of 04ca:300f AR3012 device
Dmitry Tunin [Sat, 2 May 2015 10:36:58 +0000 (13:36 +0300)]
Bluetooth: ath3k: add support of 04ca:300f AR3012 device

commit ec0810d2ac1c932dad48f45da67e3adc5c5449a1 upstream.

T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=300f Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agonfs: increase size of EXCHANGE_ID name string buffer
Jeff Layton [Tue, 9 Jun 2015 23:43:56 +0000 (19:43 -0400)]
nfs: increase size of EXCHANGE_ID name string buffer

commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.

The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.

Reported-by: Michael Skralivetsky <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
6 years agommc: card: Fixup request missing in mmc_blk_issue_rw_rq
Ding Wang [Mon, 18 May 2015 12:14:15 +0000 (20:14 +0800)]
mmc: card: Fixup request missing in mmc_blk_issue_rw_rq

commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream.

The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
may cause new coming request permanent missing when the ongoing
request (previoulsy started) complete end.

The problem scenario is as follows:
(1) Request A is ongoing;
(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
(3) Request A encounters the MMC_BLK_CMD_ERR error;
(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
    end request A completed and return zero. Continue the error handling,
    suppose mmc_blk_reset() reset device success;
(5) Continue the execution, while loop completed because variable ret
    is zero now;
(6) Finally, mmc_blk_issue_rw_rq() return without processing request B.

The process related to the missing request may wait that IO request
complete forever, possibly crashing the application or hanging the system.

Fix this issue by starting new request when reset success.

Signed-off-by: Ding Wang <>
Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support")
Signed-off-by: Ulf Hansson <>
Signed-off-by: Ben Hutchings <>
6 years agoideapad: fix software rfkill setting
Arnd Bergmann [Sat, 13 Jun 2015 13:23:33 +0000 (15:23 +0200)]
ideapad: fix software rfkill setting

commit 4b200b4604bec3388426159f1656109d19fadf6e upstream.

This fixes a several year old regression that I found while trying
to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
to send a command to the embedded controller through ACPI, but
as of c1f73658ed, it sends the index of the rfkill device instead
of the command, and ignores the opcode field.

This changes it back to the original behavior, which indeed
flips the rfkill state as seen in the debugfs interface.

Signed-off-by: Arnd Bergmann <>
Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)")
Signed-off-by: Darren Hart <>
[bwh: Backported to 3.2: device private data is just the device index, not a
Signed-off-by: Ben Hutchings <>
6 years agojbd2: fix ocfs2 corrupt when updating journal superblock fails
Joseph Qi [Mon, 15 Jun 2015 18:36:01 +0000 (14:36 -0400)]
jbd2: fix ocfs2 corrupt when updating journal superblock fails

commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream.

If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang <>
Signed-off-by: Joseph Qi <>
Signed-off-by: Theodore Ts'o <>
Tested-by: Yiwen Jiang <>
Cc: Junxiao Bi <>
[bwh: Backported to 3.2:
 - Adjust context
 - Don't drop j_checkpoint_mutex where we don't hold it]
Signed-off-by: Ben Hutchings <>
6 years agojbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()
Dmitry Monakhov [Mon, 15 Jun 2015 04:18:02 +0000 (00:18 -0400)]
jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()

commit b4f1afcd068f6e533230dfed00782cd8a907f96b upstream.

jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start()
So allocations should be done with GFP_NOFS

[Full stack trace snipped from 3.10-rh7]
[<ffffffff815c4bd4>] dump_stack+0x19/0x1b
[<ffffffff8105dba1>] warn_slowpath_common+0x61/0x80
[<ffffffff8105dcca>] warn_slowpath_null+0x1a/0x20
[<ffffffff815c2142>] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17
[<ffffffff8119c045>] kmem_cache_alloc+0x55/0x210
[<ffffffff811477f5>] ? mempool_alloc_slab+0x15/0x20
[<ffffffff811477f5>] mempool_alloc_slab+0x15/0x20
[<ffffffff81147939>] mempool_alloc+0x69/0x170
[<ffffffff815cb69e>] ? _raw_spin_unlock_irq+0xe/0x20
[<ffffffff8109160d>] ? finish_task_switch+0x5d/0x150
[<ffffffff811f1a8e>] bio_alloc_bioset+0x1be/0x2e0
[<ffffffff8127ee49>] blkdev_issue_flush+0x99/0x120
[<ffffffffa019a733>] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] -->GFP_KERNEL
[<ffffffffa019aca1>] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2]
[<ffffffffa019afc7>] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2]
[<ffffffffa01952d8>] start_this_handle+0x2d8/0x550 [jbd2]
[<ffffffff811b02a9>] ? __memcg_kmem_put_cache+0x29/0x30
[<ffffffff8119c120>] ? kmem_cache_alloc+0x130/0x210
[<ffffffffa019573a>] jbd2__journal_start+0xba/0x190 [jbd2]
[<ffffffff811532ce>] ? lru_cache_add+0xe/0x10
[<ffffffffa01c9549>] ? ext4_da_write_begin+0xf9/0x330 [ext4]
[<ffffffffa01f2c77>] __ext4_journal_start_sb+0x77/0x160 [ext4]
[<ffffffffa01c9549>] ext4_da_write_begin+0xf9/0x330 [ext4]
[<ffffffff811446ec>] generic_file_buffered_write_iter+0x10c/0x270
[<ffffffff81146918>] __generic_file_write_iter+0x178/0x390
[<ffffffff81146c6b>] __generic_file_aio_write+0x8b/0xb0
[<ffffffff81146ced>] generic_file_aio_write+0x5d/0xc0
[<ffffffffa01bf289>] ext4_file_write+0xa9/0x450 [ext4]
[<ffffffff811c31d9>] ? pipe_read+0x379/0x4f0
[<ffffffff811b93f0>] do_sync_write+0x90/0xe0
[<ffffffff811b9b6d>] vfs_write+0xbd/0x1e0
[<ffffffff811ba5b8>] SyS_write+0x58/0xb0
[<ffffffff815d4799>] system_call_fastpath+0x16/0x1b

Signed-off-by: Dmitry Monakhov <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agojbd2: issue cache flush after checkpointing even with internal journal
Jan Kara [Wed, 14 Mar 2012 02:22:54 +0000 (22:22 -0400)]
jbd2: issue cache flush after checkpointing even with internal journal

commit 79feb521a44705262d15cc819a4117a447b11ea7 upstream.

When we reach jbd2_cleanup_journal_tail(), there is no guarantee that
checkpointed buffers are on a stable storage - especially if buffers were
written out by jbd2_log_do_checkpoint(), they are likely to be only in disk's
caches. Thus when we update journal superblock effectively removing old
transaction from journal, this write of superblock can get to stable storage
before those checkpointed buffers which can result in filesystem corruption
after a crash. Thus we must unconditionally issue a cache flush before we
update journal superblock in these cases.

A similar problem can also occur if journal superblock is written only in
disk's caches, other transaction starts reusing space of the transaction
cleaned from the log and power failure happens. Subsequent journal replay would
still try to replay the old transaction but some of it's blocks may be already
overwritten by the new transaction. For this reason we must use WRITE_FUA when
updating log tail and we must first write new log tail to disk and update
in-memory information only after that.

Signed-off-by: Jan Kara <>
Signed-off-by: "Theodore Ts'o" <>
[bwh: Prerequisite for "jbd2: fix ocfs2 corrupt when updating journal
 superblock fails".
 Backported to 3.2:
 - Adjust context
 - Drop changes to jbd2_journal_update_sb_log_tail trace event]
Signed-off-by: Ben Hutchings <>
6 years agojbd2: split updating of journal superblock and marking journal empty
Jan Kara [Tue, 13 Mar 2012 19:41:04 +0000 (15:41 -0400)]
jbd2: split updating of journal superblock and marking journal empty

commit 24bcc89c7e7c64982e6192b4952a0a92379fc341 upstream.

There are three case of updating journal superblock. In the first case, we want
to mark journal as empty (setting s_sequence to 0), in the second case we want
to update log tail, in the third case we want to update s_errno. Split these
cases into separate functions. It makes the code slightly more straightforward
and later patches will make the distinction even more important.

Signed-off-by: Jan Kara <>
Signed-off-by: "Theodore Ts'o" <>
[bwh: Prerequisite for "jbd2: fix ocfs2 corrupt when updating journal
 superblock fails".
 Backported to 3.2: drop changes to trace events.]
Signed-off-by: Ben Hutchings <>
6 years agoDisable write buffering on Toshiba ToPIC95
Ryan Underwood [Mon, 26 Jan 2015 00:07:09 +0000 (16:07 -0800)]
Disable write buffering on Toshiba ToPIC95

commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.

Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.

Signed-off-by: Ryan C. Underwood <>
Signed-off-by: Dominik Brodowski <>
Signed-off-by: Ben Hutchings <>
6 years agoext4: fix race between truncate and __ext4_journalled_writepage()
Theodore Ts'o [Sat, 13 Jun 2015 03:45:33 +0000 (23:45 -0400)]
ext4: fix race between truncate and __ext4_journalled_writepage()

commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream.

The commit cf108bca465d: "ext4: Invert the locking order of page_lock
and transaction start" caused __ext4_journalled_writepage() to drop
the page lock before the page was written back, as part of changing
the locking order to jbd2_journal_start -> page_lock.  However, this
introduced a potential race if there was a truncate racing with the
data=journalled writeback mode.

Fix this by grabbing the page lock after starting the journal handle,
and then checking to see if page had gotten truncated out from under

This fixes a number of different warnings or BUG_ON's when running
xfstests generic/086 in data=journalled mode, including:

jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
c0, 164), jh->b_transaction (  (null), 0), jh->b_next_transaction (  (null), 0), jlist 0

                - and -

kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
Call Trace:
 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
 [<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117
 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
 [<c027d883>] ? lock_buffer+0x36/0x36
 [<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22
 [<c0229139>] do_invalidatepage+0x22/0x26
 [<c0229198>] truncate_inode_page+0x5b/0x85
 [<c022934b>] truncate_inode_pages_range+0x156/0x38c
 [<c0229592>] truncate_inode_pages+0x11/0x15
 [<c022962d>] truncate_pagecache+0x55/0x71
 [<c02b913b>] ext4_setattr+0x4a9/0x560
 [<c01ca542>] ? current_kernel_time+0x10/0x44
 [<c026c4d8>] notify_change+0x1c7/0x2be
 [<c0256a00>] do_truncate+0x65/0x85
 [<c0226f31>] ? file_ra_state_init+0x12/0x29

                - and -

WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
Call Trace:
 [<c01b879f>] ? console_unlock+0x3a1/0x3ce
 [<c082cbb4>] dump_stack+0x48/0x60
 [<c0178b65>] warn_slowpath_common+0x89/0xa0
 [<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
 [<c0178bef>] warn_slowpath_null+0x14/0x18
 [<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae
 [<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d
 [<c02b2f44>] write_end_fn+0x40/0x53
 [<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a
 [<c02b59e7>] ext4_writepage+0x354/0x3b8
 [<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4
 [<c02b1b21>] ? wait_on_buffer+0x2c/0x2c
 [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
 [<c02b5a5b>] __writepage+0x10/0x2e
 [<c0225956>] write_cache_pages+0x22d/0x32c
 [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
 [<c02b6ee8>] ext4_writepages+0x102/0x607
 [<c019adfe>] ? sched_clock_local+0x10/0x10e
 [<c01a8a7c>] ? __lock_is_held+0x2e/0x44
 [<c01a8ad5>] ? lock_is_held+0x43/0x51
 [<c0226dff>] do_writepages+0x1c/0x29
 [<c0276bed>] __writeback_single_inode+0xc3/0x545
 [<c0277c07>] writeback_sb_inodes+0x21f/0x36d

Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]
Zidan Wang [Thu, 11 Jun 2015 11:14:36 +0000 (19:14 +0800)]
ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]

commit a077e81ec61e07a7f86997d045109f06719fbffe upstream.

the enum of "DAC Polarity" should be wm8960_enum[1].

Signed-off-by: Zidan Wang <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agodmaengine: mv_xor: bug fix for racing condition in descriptors cleanup
Lior Amsalem [Tue, 26 May 2015 13:07:32 +0000 (15:07 +0200)]
dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup

commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.

This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).

The cleanup function will free descriptors based on the ownership bit in
the descriptors.

Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem <>
Signed-off-by: Maxime Ripard <>
Reviewed-by: Ofer Heifetz <>
Signed-off-by: Vinod Koul <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoregulator: core: fix constraints output buffer
Stefan Wahren [Tue, 9 Jun 2015 20:09:42 +0000 (20:09 +0000)]
regulator: core: fix constraints output buffer

commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream.

The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.

Signed-off-by: Stefan Wahren <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agocdc-acm: Add support of ATOL FPrint fiscal printers
Alexey Sokolov [Tue, 2 Jun 2015 08:49:30 +0000 (11:49 +0300)]
cdc-acm: Add support of ATOL FPrint fiscal printers

commit 15bf722e6f6c0b884521a0363204532e849deb7f upstream.

ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.

Signed-off-by: Alexey Sokolov <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoath9k: fix DMA stop sequence for AR9003+
Felix Fietkau [Tue, 2 Jun 2015 08:38:32 +0000 (10:38 +0200)]
ath9k: fix DMA stop sequence for AR9003+

commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Signed-off-by: Felix Fietkau <>
Signed-off-by: Kalle Valo <>
[bwh: Backported to 3.2:
 - Also move initialisation of ret to match upstream
 - ath_drain_all_txq() takes a second parameter]
Signed-off-by: Ben Hutchings <>
6 years agoath3k: add support of 13d3:3474 AR3012 device
Dmitry Tunin [Sat, 6 Jun 2015 17:29:25 +0000 (20:29 +0300)]
ath3k: add support of 13d3:3474 AR3012 device

commit 0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 upstream.

This device requires new firmware files
 AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3474 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoath3k: Add support of 0489:e076 AR3012 device
Dmitry Tunin [Sat, 6 Jun 2015 17:25:40 +0000 (20:25 +0300)]
ath3k: Add support of 0489:e076 AR3012 device

commit 692c062e7c282164fd7cda68077f79dafd176eaf upstream.

This device requires new firmware files
 AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.

T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e076 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Dmitry Tunin <>
Signed-off-by: Marcel Holtmann <>
Signed-off-by: Ben Hutchings <>
6 years agoipr: Increase default adapter init stage change timeout
Brian King [Wed, 13 May 2015 13:50:27 +0000 (08:50 -0500)]
ipr: Increase default adapter init stage change timeout

commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.

Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.

Signed-off-by: Brian King <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agoSUNRPC: Fix a memory leak in the backchannel code
Trond Myklebust [Mon, 1 Jun 2015 19:10:25 +0000 (15:10 -0400)]
SUNRPC: Fix a memory leak in the backchannel code

commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream.

req->rq_private_buf isn't initialised when xprt_setup_backchannel calls

Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
Signed-off-by: Trond Myklebust <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoNFS: Fix size of NFSACL SETACL operations
Chuck Lever [Tue, 26 May 2015 15:53:52 +0000 (11:53 -0400)]
NFS: Fix size of NFSACL SETACL operations

commit d683cc49daf7c5afca8cd9654aaa1bf63cdf2ad9 upstream.

When encoding the NFSACL SETACL operation, reserve just the estimated
size of the ACL rather than a fixed maximum. This eliminates needless
zero padding on the wire that the server ignores.

Fixes: ee5dc7732bd5 ('NFS: Fix "kernel BUG at fs/nfs/nfs3xdr.c:1338!"')
Signed-off-by: Chuck Lever <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
6 years agofixing infinite OPEN loop in 4.0 stateid recovery
Olga Kornievskaia [Fri, 15 May 2015 15:45:31 +0000 (11:45 -0400)]
fixing infinite OPEN loop in 4.0 stateid recovery

commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream.

Problem: When an operation like WRITE receives a BAD_STATEID, even though
recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
the open state, because of clearing delegation state for the associated
inode, nfs_inode_find_state_and_recover() gets called and it makes the
same state with RECLAIM_NOGRACE flag again. As a results, when we restart
looking over the open states, we end up in the infinite loop instead of
breaking out in the next test of state flags.

Solution: unset the RECLAIM_NOGRACE set because of
calling of nfs_inode_find_state_and_recover() after returning from calling
recover_open() function.

Signed-off-by: Olga Kornievskaia <>
Signed-off-by: Trond Myklebust <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agostaging: vt6655: device_rx_srv check sk_buff is NULL
Malcolm Priestley [Sun, 31 May 2015 09:35:28 +0000 (10:35 +0100)]
staging: vt6655: device_rx_srv check sk_buff is NULL

commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 upstream.

There is a small chance that pRD->pRDInfo->skb could go NULL
while the interrupt is processing.

Put NULL check on loop to break out.

Signed-off-by: Malcolm Priestley <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agousb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
Robert Schlabbach [Mon, 25 May 2015 22:27:30 +0000 (00:27 +0200)]
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset

commit fb6d1f7df5d25299fd7b3e84b72b8851d3634764 upstream.

Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.

Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().

Verbose Problem Description:

USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.

The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.

However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of

Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.

Signed-off-by: Robert Schlabbach <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/usb_clear_port_feature/clear_port_feature/]
Signed-off-by: Ben Hutchings <>
6 years agostaging: rtl8712: prevent buffer overrun in recvbuf2recvframe
Haggai Eran [Sat, 23 May 2015 20:13:51 +0000 (23:13 +0300)]
staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

commit cab462140f8a183e3cca0b51c8b59ef715cb6148 upstream.

With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
packet are set, but the packet length is too large. Allocate enough
space to prevent memory corruption and a resulting kernel panic [1].


Signed-off-by: Haggai Eran <>
ACKed-by: Larry Finger <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: dc21285: use raw spinlock functions for nw_gpio_lock
Uwe Kleine-König [Thu, 28 May 2015 08:22:10 +0000 (10:22 +0200)]
mtd: dc21285: use raw spinlock functions for nw_gpio_lock

commit e5babdf928e5d0c432a8d4b99f20421ce14d1ab6 upstream.

Since commit bd31b85960a7 (which is in 3.2-rc1) nw_gpio_lock is a raw spinlock
that needs usage of the corresponding raw functions.

This fixes:

  drivers/mtd/maps/dc21285.c: In function 'nw_en_write':
  drivers/mtd/maps/dc21285.c:41:340: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type
    spin_lock_irqsave(&nw_gpio_lock, flags);

  In file included from include/linux/seqlock.h:35:0,
                   from include/linux/time.h:5,
                   from include/linux/stat.h:18,
                   from include/linux/module.h:10,
                   from drivers/mtd/maps/dc21285.c:8:
  include/linux/spinlock.h:299:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
   static inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
  drivers/mtd/maps/dc21285.c:43:25: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type
    spin_unlock_irqrestore(&nw_gpio_lock, flags);
  In file included from include/linux/seqlock.h:35:0,
                   from include/linux/time.h:5,
                   from include/linux/stat.h:18,
                   from include/linux/module.h:10,
                   from drivers/mtd/maps/dc21285.c:8:
  include/linux/spinlock.h:370:91: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
   static inline void spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)

Fixes: bd31b85960a7 ("locking, ARM: Annotate low level hw locks as raw")
Signed-off-by: Uwe Kleine-König <>
Signed-off-by: Brian Norris <>
Signed-off-by: Ben Hutchings <>
6 years agorcu: Correctly handle non-empty Tiny RCU callback list with none ready
Paul E. McKenney [Mon, 11 May 2015 18:13:05 +0000 (11:13 -0700)]
rcu: Correctly handle non-empty Tiny RCU callback list with none ready

commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream.

If, at the time __rcu_process_callbacks() is invoked,  there are callbacks
in Tiny RCU's callback list, but none of them are ready to be invoked,
the current list-management code will knit the non-ready callbacks out
of the list.  This can result in hangs and possibly worse.  This commit
therefore inserts a check for there being no callbacks that can be
invoked immediately.

This bug is unlikely to occur -- you have to get a new callback between
the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
__rcu_process_callbacks().  It was detected by the addition of RCU-bh
testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
mutation testing.  Although this bug was made much more likely by
915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this
did not cause the bug, but rather made it much more probable.   That
said, it takes more than 40 hours of rcutorture testing, on average,
for this bug to appear, so this fix cannot be considered an emergency.

Signed-off-by: Paul E. McKenney <>
Reviewed-by: Josh Triplett <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agousb: dwc3: gadget: return error if command sent to DEPCMD register fails
Subbaraya Sundeep Bhatta [Thu, 21 May 2015 10:16:48 +0000 (15:46 +0530)]
usb: dwc3: gadget: return error if command sent to DEPCMD register fails

commit 76e838c9f7765f9a6205b4d558d75a66104bc60d upstream.

We need to return error to caller if command is not sent to
controller succesfully.

Signed-off-by: Subbaraya Sundeep Bhatta <>
Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
6 years agodrm/radeon: take the mode_config mutex when dealing with hpds (v2)
Alex Deucher [Fri, 15 May 2015 15:48:52 +0000 (11:48 -0400)]
drm/radeon: take the mode_config mutex when dealing with hpds (v2)

commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.

Since we are messing with state in the worker.

v2: drop the changes in the mst worker

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
6 years agotty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send
Nicolas Ferre [Mon, 11 May 2015 11:00:31 +0000 (13:00 +0200)]
tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send

commit 8687634b7908c42eb700e0469e110e02833611d1 upstream.

In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...

Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.

Reported-by: Sami Pietikäinen <>
Signed-off-by: Nicolas Ferre <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agopktgen: adjust spacing in proc file interface output
Jesper Dangaard Brouer [Thu, 21 May 2015 10:16:11 +0000 (12:16 +0200)]
pktgen: adjust spacing in proc file interface output

commit d079abd181950a44cdf31daafd1662388a6c4d2e upstream.

Too many spaces were introduced in commit 63adc6fb8ac0 ("pktgen: cleanup
checkpatch warnings"), thus misaligning "src_min:" to other columns.

Fixes: 63adc6fb8ac0 ("pktgen: cleanup checkpatch warnings")
Signed-off-by: Jesper Dangaard Brouer <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits
Axel Lin [Fri, 15 May 2015 01:15:16 +0000 (09:15 +0800)]
ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits

commit 12c350050538c7dc779c083b7342bfd20f74949c upstream.

WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than

Signed-off-by: Axel Lin <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>