4 years agosh: sh7757: remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl registration
Geert Uytterhoeven [Tue, 3 Oct 2017 23:14:37 +0000 (16:14 -0700)]
sh: sh7757: remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl registration

commit d8ce38f69843a56da044e56b6c16aecfbc3c6e39 upstream.

Commit 3810e96056ff ("sh: modify pinmux for SH7757 2nd cut") renamed
GPIO_PT[JLNQ]7 to GPIO_PT[JLNQ]7_RESV, and removed the existing users
from the pinmux_pins[] array.

However, pinmux_pins[] is initialized through PINMUX_GPIO(), using
designated array initializers, where the GPIO_* enums serve as indices.
Hence entries were not really removed, but replaced by (zero-filled)
holes.  Such entries are treated as pin zero, which was registered
before, thus leading to pinctrl registration failures, as seen on

    sh-pfc pfc-sh7722: pin 0 already registered
    sh-pfc pfc-sh7722: error during pin registration
    sh-pfc pfc-sh7722: could not register: -22
    sh-pfc: probe of pfc-sh7722 failed with error -22

Remove GPIO_PT[JLNQ]7_RESV from the enum to fix this.

Fixes: 3810e96056ffddf6 ("sh: modify pinmux for SH7757 2nd cut")
Signed-off-by: Geert Uytterhoeven <>
Reviewed-by: Laurent Pinchart <>
Cc: Jacopo Mondi <>
Cc: Magnus Damm <>
Cc: Rich Felker <>
Cc: Yoshihiro Shimoda <>
Cc: Yoshinori Sato <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agosh: sh7722: remove nonexistent GPIO_PTQ7 to fix pinctrl registration
Geert Uytterhoeven [Tue, 3 Oct 2017 23:14:34 +0000 (16:14 -0700)]
sh: sh7722: remove nonexistent GPIO_PTQ7 to fix pinctrl registration

commit b78412b8300a8453b78d2c1b0b925b66493bb011 upstream.

Patch series "sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration",

Magnus Damm reported that on sh7722/Migo-R, pinctrl registration fails

    sh-pfc pfc-sh7722: pin 0 already registered
    sh-pfc pfc-sh7722: error during pin registration
    sh-pfc pfc-sh7722: could not register: -22
    sh-pfc: probe of pfc-sh7722 failed with error -22

pinmux_pins[] is initialized through PINMUX_GPIO(), using designated
array initializers, where the GPIO_* enums serve as indices.  Apparently
GPIO_PTQ7 was defined in the enum, but never used.  If enum values are
defined, but never used, pinmux_pins[] contains (zero-filled) holes.
Hence such entries are treated as pin zero, which was registered before,
and pinctrl registration fails.

I can't see how this ever worked, as at the time of commit f5e25ae52fef
("sh-pfc: Add sh7722 pinmux support"), pinmux_gpios[] in
drivers/pinctrl/sh-pfc/pfc-sh7722.c already had the hole, and
drivers/pinctrl/core.c already had the check.

Some scripting revealed a few more broken drivers:
  - sh7757 has four holes, due to nonexistent GPIO_PT[JLNQ]7_RESV.
  - sh7264 and sh7269 define GPIO_PH[0-7], but don't use it with

Patch 1 fixes the issue on sh7722, and was tested.  Patches 3-4 should
fix the issue on the other 3 SoCs, but was untested due to lack of

This patch (of 4):

On sh7722/Migo-R, pinctrl registration fails with:

    sh-pfc pfc-sh7722: pin 0 already registered
    sh-pfc pfc-sh7722: error during pin registration
    sh-pfc pfc-sh7722: could not register: -22
    sh-pfc: probe of pfc-sh7722 failed with error -22

pinmux_pins[] is initialized through PINMUX_GPIO(), using designated array
initializers, where the GPIO_* enums serve as indices.  As GPIO_PTQ7 is
defined in the enum, but never used, pinmux_pins[] contains a
(zero-filled) hole.  Hence this entry is treated as pin zero, which was
registered before, and pinctrl registration fails.

According to the datasheet, port PTQ7 does not exist.  Hence remove
GPIO_PTQ7 from the enum to fix this.

Fixes: 8d7b5b0af7e070b9 ("sh: Add sh7722 pinmux code")
Signed-off-by: Geert Uytterhoeven <>
Reported-by: Magnus Damm <>
Reviewed-by: Laurent Pinchart <>
Tested-by: Jacopo Mondi <>
Cc: Rich Felker <>
Cc: Yoshihiro Shimoda <>
Cc: Yoshinori Sato <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agokernel/params.c: align add_sysfs_param documentation with code
Jean Delvare [Tue, 3 Oct 2017 23:14:18 +0000 (16:14 -0700)]
kernel/params.c: align add_sysfs_param documentation with code

commit 630cc2b30a42c70628368a412beb4a5e5dd71abe upstream.

This parameter is named kp, so the documentation should use that.

Fixes: 9b473de87209 ("param: Fix duplicate module prefixes")
Signed-off-by: Jean Delvare <>
Acked-by: Rusty Russell <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP
Martin K. Petersen [Thu, 28 Sep 2017 01:35:12 +0000 (21:35 -0400)]
scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

commit 28a0bc4120d38a394499382ba21d6965a67a3703 upstream.

SBC-4 states:

  "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
   maximum number of LBAs that may be unmapped by an UNMAP command"

  "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
   the maximum number of contiguous logical blocks that the device server
   allows to be unmapped or written in a single WRITE SAME command."

Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.

Implement a blacklist option that can be used to accommodate devices
with this behavior.

Reported-by: Bill Kuzeja <>
Reported-by: Ewan D. Milne <>
Reviewed-by: Ewan D. Milne <>
Tested-by: Laurence Oberman <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2:
 - Keep using literals for SD_MAX_WS{16,10}_BLOCKS
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoALSA: usx2y: Suppress kernel warning at page allocation failures
Takashi Iwai [Mon, 2 Oct 2017 12:06:43 +0000 (14:06 +0200)]
ALSA: usx2y: Suppress kernel warning at page allocation failures

commit 7682e399485fe19622b6fd82510b1f4551e48a25 upstream.

The usx2y driver allocates the stream read/write buffers in continuous
pages depending on the stream setup, and this may spew the kernel
warning messages with a stack trace like:
  WARNING: CPU: 1 PID: 1846 at mm/page_alloc.c:3883
  Modules linked in:
  CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted

It may confuse user as if it were any serious error, although this is
no fatal error and the driver handles the error case gracefully.
Since the driver has already some sanity check of the given size (128
and 256 pages), it can't pass any crazy value.  So it's merely page

This patch adds __GFP_NOWARN to each caller for suppressing such
kernel warnings.  The original issue was spotted by syzkaller.

Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
4 years agol2tp: fix l2tp_eth module loading
Guillaume Nault [Thu, 28 Sep 2017 13:44:38 +0000 (15:44 +0200)]
l2tp: fix l2tp_eth module loading

commit 9f775ead5e570e7e19015b9e4e2f3dd6e71a5935 upstream.

The l2tp_eth module crashes if its netlink callbacks are run when the
pernet data aren't initialised.

We should normally register_pernet_device() before the genl callbacks.
However, the pernet data only maintain a list of l2tpeth interfaces,
and this list is never used. So let's just drop pernet handling

Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agostaging: iio: ade7759: fix signed extension bug on shift of a u8
Colin Ian King [Wed, 13 Sep 2017 17:02:02 +0000 (18:02 +0100)]
staging: iio: ade7759: fix signed extension bug on shift of a u8

commit 13ffe9a26df4e156363579b25c904dd0b1e31bfb upstream.

The current shift of st->rx[2] left shifts a u8 24 bits left,
promotes the integer to a an int and then to a unsigned u64. If
the top bit of st->rx[2] is set then we end up with all the upper
bits being set to 1. Fix this by casting st->rx[2] to a u64 before
the 24 bit left shift.

Detected by CoverityScan CID#144940 ("Unintended sign extension")

Fixes: 2919fa54ef64 ("staging: iio: meter: new driver for ADE7759 devices")
Signed-off-by: Colin Ian King <>
Signed-off-by: Jonathan Cameron <>
Signed-off-by: Ben Hutchings <>
4 years agokvm/x86: Handle async PF in RCU read-side critical sections
Boqun Feng [Fri, 29 Sep 2017 11:01:45 +0000 (19:01 +0800)]
kvm/x86: Handle async PF in RCU read-side critical sections

commit b862789aa5186d5ea3a024b7cfe0f80c3a38b980 upstream.

Sasha Levin reported a WARNING:

| WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
| rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
| WARNING: CPU: 0 PID: 6974 at kernel/rcu/tree_plugin.h:329
| rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
| CPU: 0 PID: 6974 Comm: syz-fuzzer Not tainted 4.13.0-next-20170908+ #246
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
| 1.10.1-1ubuntu1 04/01/2014
| Call Trace:
| RIP: 0010:rcu_preempt_note_context_switch kernel/rcu/tree_plugin.h:329 [inline]
| RIP: 0010:rcu_note_context_switch+0x16c/0x2210 kernel/rcu/tree.c:458
| RSP: 0018:ffff88003b2debc8 EFLAGS: 00010002
| RAX: 0000000000000001 RBX: 1ffff1000765bd85 RCX: 0000000000000000
| RDX: 1ffff100075d7882 RSI: ffffffffb5c7da20 RDI: ffff88003aebc410
| RBP: ffff88003b2def30 R08: dffffc0000000000 R09: 0000000000000001
| R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003b2def08
| R13: 0000000000000000 R14: ffff88003aebc040 R15: ffff88003aebc040
| __schedule+0x201/0x2240 kernel/sched/core.c:3292
| schedule+0x113/0x460 kernel/sched/core.c:3421
| kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158
| do_async_page_fault+0x72/0x90 arch/x86/kernel/kvm.c:271
| async_page_fault+0x22/0x30 arch/x86/entry/entry_64.S:1069
| RIP: 0010:format_decode+0x240/0x830 lib/vsprintf.c:1996
| RSP: 0018:ffff88003b2df520 EFLAGS: 00010283
| RAX: 000000000000003f RBX: ffffffffb5d1e141 RCX: ffff88003b2df670
| RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffb5d1e140
| RBP: ffff88003b2df560 R08: dffffc0000000000 R09: 0000000000000000
| R10: ffff88003b2df718 R11: 0000000000000000 R12: ffff88003b2df5d8
| R13: 0000000000000064 R14: ffffffffb5d1e140 R15: 0000000000000000
| vsnprintf+0x173/0x1700 lib/vsprintf.c:2136
| sprintf+0xbe/0xf0 lib/vsprintf.c:2386
| proc_self_get_link+0xfb/0x1c0 fs/proc/self.c:23
| get_link fs/namei.c:1047 [inline]
| link_path_walk+0x1041/0x1490 fs/namei.c:2127

This happened when the host hit a page fault, and delivered it as in an
async page fault, while the guest was in an RCU read-side critical
section.  The guest then tries to reschedule in kvm_async_pf_task_wait(),
but rcu_preempt_note_context_switch() would treat the reschedule as a
sleep in RCU read-side critical section, which is not allowed (even in
preemptible RCU).  Thus the WARN.

To cure this, make kvm_async_pf_task_wait() go to the halt path if the
PF happens in a RCU read-side critical section.

Reported-by: Sasha Levin <>
Cc: "Paul E. McKenney" <>
Cc: Peter Zijlstra <>
Signed-off-by: Boqun Feng <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoKVM: Do not take reference to mm during async #PF
Gleb Natapov [Wed, 2 May 2012 12:04:02 +0000 (15:04 +0300)]
KVM: Do not take reference to mm during async #PF

commit 62c49cc976af84cb0ffcb5ec07ee88da1a94e222 upstream.

It turned to be totally unneeded. The reason the code was introduced is
so that KVM can prefault swapped in page, but prefault can fail even
if mm is pinned since page table can change anyway. KVM handles this
situation correctly though and does not inject spurious page faults.

 "INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected" warning while
 running LTP inside a KVM guest using the recent -next kernel.

Reported-by: Sasha Levin <>
Signed-off-by: Gleb Natapov <>
Signed-off-by: Avi Kivity <>
Signed-off-by: Ben Hutchings <>
4 years agosched/sysctl: Check user input value of sysctl_sched_time_avg
Ethan Zhao [Mon, 4 Sep 2017 05:59:34 +0000 (13:59 +0800)]
sched/sysctl: Check user input value of sysctl_sched_time_avg

commit 5ccba44ba118a5000cccc50076b0344632459779 upstream.

System will hang if user set sysctl_sched_time_avg to 0:

  [root@XXX ~]# sysctl kernel.sched_time_avg_ms=0

  Stack traceback for pid 0
  0xffff883f6406c600 0 0 1 3 R 0xffff883f6406cf50 *swapper/3
  ffff883f7ccc3ae8 0000000000000018 ffffffff810c4dd0 0000000000000000
  0000000000017800 ffff883f7ccc3d78 0000000000000003 ffff883f7ccc3bf8
  ffffffff810c4fc9 ffff883f7ccc3c08 00000000810c5043 ffff883f7ccc3c08
  Call Trace:
  <IRQ> [<ffffffff810c4dd0>] ? update_group_capacity+0x110/0x200
  [<ffffffff810c4fc9>] ? update_sd_lb_stats+0x109/0x600
  [<ffffffff810c5507>] ? find_busiest_group+0x47/0x530
  [<ffffffff810c5b84>] ? load_balance+0x194/0x900
  [<ffffffff810ad5ca>] ? update_rq_clock.part.83+0x1a/0xe0
  [<ffffffff810c6d42>] ? rebalance_domains+0x152/0x290
  [<ffffffff810c6f5c>] ? run_rebalance_domains+0xdc/0x1d0
  [<ffffffff8108a75b>] ? __do_softirq+0xfb/0x320
  [<ffffffff8108ac85>] ? irq_exit+0x125/0x130
  [<ffffffff810b3a17>] ? scheduler_ipi+0x97/0x160
  [<ffffffff81052709>] ? smp_reschedule_interrupt+0x29/0x30
  [<ffffffff8173a1be>] ? reschedule_interrupt+0x6e/0x80
   <EOI> [<ffffffff815bc83c>] ? cpuidle_enter_state+0xcc/0x230
  [<ffffffff815bc80c>] ? cpuidle_enter_state+0x9c/0x230
  [<ffffffff815bc9d7>] ? cpuidle_enter+0x17/0x20
  [<ffffffff810cd6dc>] ? cpu_startup_entry+0x38c/0x420
  [<ffffffff81053373>] ? start_secondary+0x173/0x1e0

Because divide-by-zero error happens in function:

          total = sched_avg_period() + delta;
          used = div_u64(avg, total);

To fix this issue, check user input value of sysctl_sched_time_avg, keep
it unchanged when hitting invalid input, and set the minimum limit of
sysctl_sched_time_avg to 1 ms.

Reported-by: James Puthukattukaran <>
Signed-off-by: Ethan Zhao <>
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
4 years agopacket: only test po->has_vnet_hdr once in packet_snd
Willem de Bruijn [Tue, 26 Sep 2017 16:20:17 +0000 (12:20 -0400)]
packet: only test po->has_vnet_hdr once in packet_snd

commit da7c9561015e93d10fe6aab73e9288e0d09d65a6 upstream.

Packet socket option po->has_vnet_hdr can be updated concurrently with
other operations if no ring is attached.

Do not test the option twice in packet_snd, as the value may change in
between calls. A race on setsockopt disable may cause a packet > mtu
to be sent without having GSO options set.

Fixes: bfd5f4a3d605 ("packet: Add GSO/csum offload support.")
Signed-off-by: Willem de Bruijn <>
Reviewed-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction
Yoshihiro Shimoda [Wed, 27 Sep 2017 09:47:13 +0000 (18:47 +0900)]
usb: renesas_usbhs: fix usbhsf_fifo_clear() for RX direction

commit 0a2ce62b61f2c76d0213edf4e37aaf54a8ddf295 upstream.

This patch fixes an issue that the usbhsf_fifo_clear() is possible
to cause 10 msec delay if the pipe is RX direction and empty because
the FRDY bit will never be set to 1 in such case.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
4 years agousb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe
Yoshihiro Shimoda [Wed, 27 Sep 2017 09:47:12 +0000 (18:47 +0900)]
usb: renesas_usbhs: fix the BCLR setting condition for non-DCP pipe

commit 6124607acc88fffeaadf3aacfeb3cc1304c87387 upstream.

This patch fixes an issue that the driver sets the BCLR bit of
{C,Dn}FIFOCTR register to 1 even when it's non-DCP pipe and
the FRDY bit of {C,Dn}FIFOCTR register is set to 1.

Fixes: e8d548d54968 ("usb: renesas_usbhs: fifo became independent from pipe.")
Signed-off-by: Yoshihiro Shimoda <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: dummy-hcd: Fix erroneous synchronization change
Alan Stern [Tue, 26 Sep 2017 19:15:49 +0000 (15:15 -0400)]
USB: dummy-hcd: Fix erroneous synchronization change

commit 7dbd8f4cabd96db5a50513de9d83a8105a5ffc81 upstream.

A recent change to the synchronization in dummy-hcd was incorrect.
The issue was that dummy_udc_stop() contained no locking and therefore
could race with various gadget driver callbacks, and the fix was to
add locking and issue the callbacks with the private spinlock held.

UDC drivers aren't supposed to do this.  Gadget driver callback
routines are allowed to invoke functions in the UDC driver, and these
functions will generally try to acquire the private spinlock.  This
would deadlock the driver.

The correct solution is to drop the spinlock before issuing callbacks,
and avoid races by emulating the synchronize_irq() call that all real
UDC drivers must perform in their ->udc_stop() routines after
disabling interrupts.  This involves adding a flag to dummy-hcd's
private structure to keep track of whether interrupts are supposed to
be enabled, and adding a counter to keep track of ongoing callbacks so
that dummy_udc_stop() can wait for them all to finish.

A real UDC driver won't receive disconnect, reset, suspend, resume, or
setup events once it has disabled interrupts.  dummy-hcd will receive
them but won't try to issue any gadget driver callbacks, which should
be just as good.

Signed-off-by: Alan Stern <>
Fixes: f16443a034c7 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
Alan Stern [Tue, 13 Jun 2017 19:23:42 +0000 (15:23 -0400)]
USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks

commit f16443a034c7aa359ddf6f0f9bc40d01ca31faea upstream.

Using the syzkaller kernel fuzzer, Andrey Konovalov generated the
following error in gadgetfs:

> BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
> kernel/locking/lockdep.c:3246
> Read of size 8 at addr ffff88003a2bdaf8 by task kworker/3:1/903
> CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x230/0x340 mm/kasan/report.c:408
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
>  __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
>  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
>  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
>  _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
>  spin_lock include/linux/spinlock.h:299 [inline]
>  gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
>  set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
>  dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
>  rh_call_control drivers/usb/core/hcd.c:689 [inline]
>  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
>  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
>  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
>  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
>  usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
>  hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
>  hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
>  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
>  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
>  port_event drivers/usb/core/hub.c:5105 [inline]
>  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
>  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
>  process_scheduled_works kernel/workqueue.c:2157 [inline]
>  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
>  kthread+0x363/0x440 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
> Allocated by task 9958:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
>  kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
>  kmalloc include/linux/slab.h:492 [inline]
>  kzalloc include/linux/slab.h:665 [inline]
>  dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
>  gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
>  mount_single+0xf6/0x160 fs/super.c:1192
>  gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
>  mount_fs+0x9c/0x2d0 fs/super.c:1223
>  vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
>  vfs_kern_mount fs/namespace.c:2509 [inline]
>  do_new_mount fs/namespace.c:2512 [inline]
>  do_mount+0x41b/0x2d90 fs/namespace.c:2834
>  SYSC_mount fs/namespace.c:3050 [inline]
>  SyS_mount+0xb0/0x120 fs/namespace.c:3027
>  entry_SYSCALL_64_fastpath+0x1f/0xbe
> Freed by task 9960:
>  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>  set_track mm/kasan/kasan.c:525 [inline]
>  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
>  slab_free_hook mm/slub.c:1357 [inline]
>  slab_free_freelist_hook mm/slub.c:1379 [inline]
>  slab_free mm/slub.c:2961 [inline]
>  kfree+0xed/0x2b0 mm/slub.c:3882
>  put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163
>  gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027
>  deactivate_locked_super+0x8d/0xd0 fs/super.c:309
>  deactivate_super+0x21e/0x310 fs/super.c:340
>  cleanup_mnt+0xb7/0x150 fs/namespace.c:1112
>  __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119
>  task_work_run+0x1a0/0x280 kernel/task_work.c:116
>  exit_task_work include/linux/task_work.h:21 [inline]
>  do_exit+0x18a8/0x2820 kernel/exit.c:878
>  do_group_exit+0x14e/0x420 kernel/exit.c:982
>  get_signal+0x784/0x1780 kernel/signal.c:2318
>  do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808
>  exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157
>  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
>  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
>  entry_SYSCALL_64_fastpath+0xbc/0xbe
> The buggy address belongs to the object at ffff88003a2bdae0
>  which belongs to the cache kmalloc-1024 of size 1024
> The buggy address is located 24 bytes inside of
>  1024-byte region [ffff88003a2bdae0ffff88003a2bdee0)
> The buggy address belongs to the page:
> page:ffffea0000e8ae00 count:1 mapcount:0 mapping:          (null)
> index:0x0 compound_mapcount: 0
> flags: 0x100000000008100(slab|head)
> raw: 0100000000008100 0000000000000000 0000000000000000 0000000100170017
> raw: ffffea0000ed3020 ffffea0000f5f820 ffff88003e80efc0 0000000000000000
> page dumped because: kasan: bad access detected
> Memory state around the buggy address:
>  ffff88003a2bd980: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88003a2bda00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >ffff88003a2bda80: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb
>                                                                 ^
>  ffff88003a2bdb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff88003a2bdb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================

What this means is that the gadgetfs_suspend() routine was trying to
access dev->lock after it had been deallocated.  The root cause is a
race in the dummy_hcd driver; the dummy_udc_stop() routine can race
with the rest of the driver because it contains no locking.  And even
when proper locking is added, it can still race with the
set_link_state() function because that function incorrectly drops the
private spinlock before invoking any gadget driver callbacks.

The result of this race, as seen above, is that set_link_state() can
invoke a callback in gadgetfs even after gadgetfs has been unbound
from dummy_hcd's UDC and its private data structures have been

include/linux/usb/gadget.h documents that the ->reset, ->disconnect,
->suspend, and ->resume callbacks may be invoked in interrupt context.
In general this is necessary, to prevent races with gadget driver
removal.  This patch fixes dummy_hcd to retain the spinlock across
these calls, and it adds a spinlock acquisition to dummy_udc_stop() to
prevent the race.

The net2280 driver makes the same mistake of dropping the private
spinlock for its ->disconnect and ->reset callback invocations.  The
patch fixes it too.

Lastly, since gadgetfs_suspend() may be invoked in interrupt context,
it cannot assume that interrupts are enabled when it runs.  It must
use spin_lock_irqsave() instead of spin_lock_irq().  The patch fixes
that bug as well.

Signed-off-by: Alan Stern <>
Reported-and-tested-by: Andrey Konovalov <>
Acked-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop changes in net2280
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: dummy-hcd: fix infinite-loop resubmission bug
Alan Stern [Tue, 26 Sep 2017 19:15:40 +0000 (15:15 -0400)]
USB: dummy-hcd: fix infinite-loop resubmission bug

commit 0173a68bfb0ad1c72a6ee39cc485aa2c97540b98 upstream.

The dummy-hcd HCD/UDC emulator tries not to do too much work during
each timer interrupt.  But it doesn't try very hard; currently all
it does is limit the total amount of bulk data transferred.  Other
transfer types aren't limited, and URBs that transfer no data (because
of an error, perhaps) don't count toward the limit, even though on a
real USB bus they would consume at least a minimum overhead.

This means it's possible to get the driver stuck in an infinite loop,
for example, if the host class driver resubmits an URB every time it
completes (which is common for interrupt URBs).  Each time the URB is
resubmitted it gets added to the end of the pending-URBs list, and
dummy-hcd doesn't stop until that list is empty.  Andrey Konovalov was
able to trigger this failure mode using the syzkaller fuzzer.

This patch fixes the infinite-loop problem by restricting the URBs
handled during each timer interrupt to those that were already on the
pending list when the interrupt routine started.  Newly added URBs
won't be processed until the next timer interrupt.  The problem of
properly accounting for non-bulk bandwidth (as well as packet and
transaction overhead) is not addressed here.

Signed-off-by: Alan Stern <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agovfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
Andreas Gruenbacher [Mon, 25 Sep 2017 10:23:03 +0000 (12:23 +0200)]
vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets

commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.

In generic_file_llseek_size, return -ENXIO for negative offsets as well
as offsets beyond EOF.  This affects filesystems which don't implement
SEEK_HOLE / SEEK_DATA internally, possibly because they don't support

Fixes xfstest generic/448.

Signed-off-by: Andreas Gruenbacher <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: s/eof/i_size_read(inode)/]
Signed-off-by: Ben Hutchings <>
4 years agoKEYS: prevent creating a different user's keyrings
Eric Biggers [Mon, 18 Sep 2017 18:37:03 +0000 (11:37 -0700)]
KEYS: prevent creating a different user's keyrings

commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.

It was possible for an unprivileged user to create the user and user
session keyrings for another user.  For example:

    sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                           keyctl add keyring _uid_ses.4000 "" @u
                           sleep 15' &
    sleep 1
    sudo -u '#4000' keyctl describe @u
    sudo -u '#4000' keyctl describe @us

This is problematic because these "fake" keyrings won't have the right
permissions.  In particular, the user who created them first will own
them and will have full access to them via the possessor permissions,
which can be used to compromise the security of a user's keys:

    -4: alswrv-----v------------  3000     0 keyring: _uid.4000
    -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000

Fix it by marking user and user session keyrings with a flag
KEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session
keyring by name, skip all keyrings that don't have the flag set.

Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings unless they're accessed")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoKEYS: fix key refcount leak in keyctl_read_key()
Eric Biggers [Mon, 18 Sep 2017 18:36:31 +0000 (11:36 -0700)]
KEYS: fix key refcount leak in keyctl_read_key()

commit 7fc0786d956d9e59b68d282be9b156179846ea3d upstream.

In keyctl_read_key(), if key_permission() were to return an error code
other than EACCES, we would leak a the reference to the key.  This can't
actually happen currently because key_permission() can only return an
error code other than EACCES if security_key_permission() does, only
SELinux and Smack implement that hook, and neither can return an error
code other than EACCES.  But it should still be fixed, as it is a bug
waiting to happen.

Fixes: 29db91906340 ("[PATCH] Keys: Add LSM hooks for key management [try #3]")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
Signed-off-by: Ben Hutchings <>
4 years agoKEYS: fix key refcount leak in keyctl_assume_authority()
Eric Biggers [Mon, 18 Sep 2017 18:36:12 +0000 (11:36 -0700)]
KEYS: fix key refcount leak in keyctl_assume_authority()

commit 884bee0215fcc239b30c062c37ca29077005e064 upstream.

In keyctl_assume_authority(), if keyctl_change_reqkey_auth() were to
fail, we would leak the reference to the 'authkey'.  Currently this can
only happen if prepare_creds() fails to allocate memory.  But it still
should be fixed, as it is a more severe bug waiting to happen.

This patch also moves the read of 'authkey->serial' to before the
reference to the authkey is dropped.  Doing the read after dropping the
reference is very fragile because it assumes we still hold another
reference to the key.  (Which we do, in current->cred->request_key_auth,
but there's no reason not to write it in the "obviously correct" way.)

Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
Signed-off-by: Ben Hutchings <>
4 years agoKEYS: don't revoke uninstantiated key in request_key_auth_new()
Eric Biggers [Thu, 21 Sep 2017 20:57:41 +0000 (13:57 -0700)]
KEYS: don't revoke uninstantiated key in request_key_auth_new()

commit f7b48cf08fa63a68b59c2894806ee478216d7f91 upstream.

If key_instantiate_and_link() were to fail (which fortunately isn't
possible currently), the call to key_revoke(authkey) would crash with a
NULL pointer dereference in request_key_auth_revoke() because the key
has not yet been instantiated.

Fix this by removing the call to key_revoke().  key_put() is sufficient,
as it's not possible for an uninstantiated authkey to have been used for
anything yet.

Fixes: b5f545c880a2 ("[PATCH] keys: Permit running process to instantiate keys")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
Signed-off-by: Ben Hutchings <>
4 years agoKEYS: fix cred refcount leak in request_key_auth_new()
Eric Biggers [Thu, 21 Sep 2017 20:57:40 +0000 (13:57 -0700)]
KEYS: fix cred refcount leak in request_key_auth_new()

commit 44d8143340a99b167c74365e844516b73523c087 upstream.

In request_key_auth_new(), if key_alloc() or key_instantiate_and_link()
were to fail, we would leak a reference to the 'struct cred'.  Currently
this can only happen if key_alloc() fails to allocate memory.  But it
still should be fixed, as it is a more severe bug waiting to happen.

Fix it by cleaning things up to use a helper function which frees a
'struct request_key_auth' correctly.

Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers <>
Signed-off-by: David Howells <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: gadgetfs: Fix crash caused by inadequate synchronization
Alan Stern [Thu, 21 Sep 2017 17:23:58 +0000 (13:23 -0400)]
USB: gadgetfs: Fix crash caused by inadequate synchronization

commit 520b72fc64debf8a86c3853b8e486aa5982188f0 upstream.

The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written
before the UDC and composite frameworks were adopted; it is a legacy
driver.  As such, it expects that once bound to a UDC controller, it
will not be unbound until it unregisters itself.

However, the UDC framework does unbind function drivers while they are
still registered.  When this happens, it can cause the gadgetfs driver
to misbehave or crash.  For example, userspace can cause a crash by
opening the device file and doing an ioctl call before setting up a
configuration (found by Andrey Konovalov using the syzkaller fuzzer).

This patch adds checks and synchronization to prevent these bad
behaviors.  It adds a udc_usage counter that the driver increments at
times when it is using a gadget interface without holding the private
spinlock.  The unbind routine waits for this counter to go to 0 before
returning, thereby ensuring that the UDC is no longer in use.

The patch also adds a check in the dev_ioctl() routine to make sure
the driver is bound to a UDC before dereferencing the gadget pointer,
and it makes destroy_ep_files() synchronize with the endpoint I/O
routines, to prevent the user from accessing an endpoint data
structure after it has been removed.

Signed-off-by: Alan Stern <>
Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Acked-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Expand locked section in ep0_write() to match upstream
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: gadgetfs: fix copy_to_user while holding spinlock
Alan Stern [Thu, 21 Sep 2017 20:12:01 +0000 (16:12 -0400)]
USB: gadgetfs: fix copy_to_user while holding spinlock

commit 6e76c01e71551cb221c1f3deacb9dcd9a7346784 upstream.

The gadgetfs driver as a long-outstanding FIXME, regarding a call of
copy_to_user() made while holding a spinlock.  This patch fixes the
issue by dropping the spinlock and using the dev->udc_usage mechanism
introduced by another recent patch to guard against status changes
while the lock isn't held.

Signed-off-by: Alan Stern <>
Reported-by: Andrey Konovalov <>
Acked-by: Felipe Balbi <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agousb: gadget: fix spinlock dead lock in gadgetfs
Bin Liu [Thu, 26 May 2016 16:43:45 +0000 (11:43 -0500)]
usb: gadget: fix spinlock dead lock in gadgetfs

commit d246dcb2331c5783743720e6510892eb1d2801d9 upstream.

[   40.467381] =============================================
[   40.473013] [ INFO: possible recursive locking detected ]
[   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
[   40.483466] ---------------------------------------------
[   40.489098] usb/733 is trying to acquire lock:
[   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
[   40.502882]
[   40.502882] but task is already holding lock:
[   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[   40.517811]
[   40.517811] other info that might help us debug this:
[   40.524623]  Possible unsafe locking scenario:
[   40.524623]
[   40.530798]        CPU0
[   40.533346]        ----
[   40.535894]   lock(&(&dev->lock)->rlock);
[   40.540088]   lock(&(&dev->lock)->rlock);
[   40.544284]
[   40.544284]  *** DEADLOCK ***
[   40.544284]
[   40.550461]  May be due to missing lock nesting notation
[   40.550461]
[   40.557544] 2 locks held by usb/733:
[   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
[   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[   40.578523]
[   40.578523] stack backtrace:
[   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
[   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
[   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
[   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
[   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
[   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
[   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
[   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
[   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
[   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
[   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
[   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
[   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
[   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
[   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)

This is caused by the spinlock bug in ep0_read().
Fix the two other deadlock sources in gadgetfs_setup() too.

Signed-off-by: Bin Liu <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
4 years agousb-storage: unusual_devs entry to fix write-access regression for Seagate external...
Alan Stern [Thu, 21 Sep 2017 19:59:30 +0000 (15:59 -0400)]
usb-storage: unusual_devs entry to fix write-access regression for Seagate external drives

commit 113f6eb6d50cfa5e2a1cdcf1678b12661fa272ab upstream.

Kris Lindgren reports that without the NO_WP_DETECT flag, his Seagate
external disk drive fails all write accesses.  This regresssion dates
back approximately to the start of the 4.x kernel releases.

Signed-off-by: Alan Stern <>
Reported-by: Kris Lindgren <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agoInput: uinput - avoid FF flush when destroying device
Dmitry Torokhov [Sat, 2 Sep 2017 00:13:43 +0000 (17:13 -0700)]
Input: uinput - avoid FF flush when destroying device

commit e8b95728f724797f958912fd9b765a695595d3a6 upstream.

Normally, when input device supporting force feedback effects is being
destroyed, we try to "flush" currently playing effects, so that the
physical device does not continue vibrating (or executing other effects).
Unfortunately this does not work well for uinput as flushing of the effects
deadlocks with the destroy action:

- if device is being destroyed because the file descriptor is being closed,
  then there is noone to even service FF requests;

- if device is being destroyed because userspace sent UI_DEV_DESTROY,
  while theoretically it could be possible to service FF requests,
  userspace is unlikely to do so (they'd need to make sure FF handling
  happens on a separate thread) even if kernel solves the issue with FF
  ioctls deadlocking with UI_DEV_DESTROY ioctl on udev->mutex.

To avoid lockups like the one below, let's install a custom input device
flush handler, and avoid trying to flush force feedback effects when we
destroying the device, and instead rely on uinput to shut off the device

NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
 <<EOE>>  [<ffffffff817a0307>] _raw_spin_lock_irqsave+0x37/0x40
 [<ffffffff810e633d>] complete+0x1d/0x50
 [<ffffffffa00ba08c>] uinput_request_done+0x3c/0x40 [uinput]
 [<ffffffffa00ba587>] uinput_request_submit.part.7+0x47/0xb0 [uinput]
 [<ffffffffa00bb62b>] uinput_dev_erase_effect+0x5b/0x76 [uinput]
 [<ffffffff815d91ad>] erase_effect+0xad/0xf0
 [<ffffffff815d929d>] flush_effects+0x4d/0x90
 [<ffffffff815d4cc0>] input_flush_device+0x40/0x60
 [<ffffffff815daf1c>] evdev_cleanup+0xac/0xc0
 [<ffffffff815daf5b>] evdev_disconnect+0x2b/0x60
 [<ffffffff815d74ac>] __input_unregister_device+0xac/0x150
 [<ffffffff815d75f7>] input_unregister_device+0x47/0x70
 [<ffffffffa00bac45>] uinput_destroy_device+0xb5/0xc0 [uinput]
 [<ffffffffa00bb2de>] uinput_ioctl_handler.isra.9+0x65e/0x740 [uinput]
 [<ffffffff811231ab>] ? do_futex+0x12b/0xad0
 [<ffffffffa00bb3f8>] uinput_ioctl+0x18/0x20 [uinput]
 [<ffffffff81241248>] do_vfs_ioctl+0x298/0x480
 [<ffffffff81337553>] ? security_file_ioctl+0x43/0x60
 [<ffffffff812414a9>] SyS_ioctl+0x79/0x90
 [<ffffffff817a04ee>] entry_SYSCALL_64_fastpath+0x12/0x71

Reported-by: Rodrigo Rivas Costa <>
Reported-by: Clément VUCHENER <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
4 years agocrypto: talitos - fix sha224
LEROY Christophe [Wed, 13 Sep 2017 10:44:51 +0000 (12:44 +0200)]
crypto: talitos - fix sha224

commit afd62fa26343be6445479e75de9f07092a061459 upstream.

Kernel crypto tests report the following error at startup

[    2.752626] alg: hash: Test 4 failed for sha224-talitos
[    2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22

This patch fixes it

Signed-off-by: Christophe Leroy <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: cp210x: add support for ELV TFD500
Andreas Engel [Mon, 18 Sep 2017 19:11:57 +0000 (21:11 +0200)]
USB: serial: cp210x: add support for ELV TFD500

commit c496ad835c31ad639b6865714270b3003df031f6 upstream.

Add the USB device id for the ELV TFD500 data logger.

Signed-off-by: Andreas Engel <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agos390/mm: fix write access check in gup_huge_pmd()
Gerald Schaefer [Mon, 18 Sep 2017 14:51:51 +0000 (16:51 +0200)]
s390/mm: fix write access check in gup_huge_pmd()

commit ba385c0594e723d41790ecfb12c610e6f90c7785 upstream.

The check for the _SEGMENT_ENTRY_PROTECT bit in gup_huge_pmd() is the
wrong way around. It must not be set for write==1, and not be checked for
write==0. Fix this similar to how it was fixed for ptes long time ago in
commit 25591b070336 ("[S390] fix get_user_pages_fast").

One impact of this bug would be unnecessarily using the gup slow path for
write==0 on r/w mappings. A potentially more severe impact would be that
gup_huge_pmd() will succeed for write==1 on r/o mappings.

Signed-off-by: Gerald Schaefer <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2:
 - Segment flag names are different
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousb: pci-quirks.c: Corrected timeout values used in handshake
Jim Dickerson [Mon, 18 Sep 2017 14:39:14 +0000 (17:39 +0300)]
usb: pci-quirks.c: Corrected timeout values used in handshake

commit 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Signed-off-by: Jim Dickerson <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agoxhci: fix finding correct bus_state structure for USB 3.1 hosts
Mathias Nyman [Mon, 18 Sep 2017 14:39:13 +0000 (17:39 +0300)]
xhci: fix finding correct bus_state structure for USB 3.1 hosts

commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agousb: Increase quirk delay for USB devices
Dmitry Fleytman [Tue, 5 Sep 2017 08:40:56 +0000 (11:40 +0300)]
usb: Increase quirk delay for USB devices

commit b2a542bbb3081dbd64acc8929c140d196664c406 upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

The workaround is introducing delay for some USB operations.

According to our testing, delay introduced by original commit
is not long enough and in rare cases we still see issues described
by the aforementioned commit.

This patch increases delays introduced by original commit.
Having this patch applied we do not see those problems anymore.

Signed-off-by: Dmitry Fleytman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agouwb: properly check kthread_run return value
Andrey Konovalov [Thu, 14 Sep 2017 12:30:55 +0000 (14:30 +0200)]
uwb: properly check kthread_run return value

commit bbf26183b7a6236ba602f4d6a2f7cade35bba043 upstream.

uwbd_start() calls kthread_run() and checks that the return value is
not NULL. But the return value is not NULL in case kthread_run() fails,
it takes the form of ERR_PTR(-EINTR).

Use IS_ERR() instead.

Also add a check to uwbd_stop().

Signed-off-by: Andrey Konovalov <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agouwb: ensure that endpoint is interrupt
Andrey Konovalov [Thu, 14 Sep 2017 14:52:59 +0000 (16:52 +0200)]
uwb: ensure that endpoint is interrupt

commit 70e743e4cec3733dc13559f6184b35d358b9ef3f upstream.

hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no
check for that, which results in a WARNING in USB core code, when a bad
USB descriptor is provided from a device:

usb 1-1: BOGUS urb xfer, pipe 1 != type 3
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bdc1a00 task.stack: ffff88006bde8000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282
RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000
RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a
RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff
R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f
R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90
FS:  0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0
Call Trace:
 hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710
 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361
 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858
 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:385
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
 __device_attach+0x269/0x3c0 drivers/base/dd.c:682
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
 device_add+0xcf9/0x1640 drivers/base/core.c:1703
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4890
 hub_port_connect_change drivers/usb/core/hub.c:4996
 port_event drivers/usb/core/hub.c:5102
 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
 kthread+0x324/0x3f0 kernel/kthread.c:231
 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
---[ end trace 55d741234124cfc3 ]---

Check that endpoint is interrupt.

Found by syzkaller.

Signed-off-by: Andrey Konovalov <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: option: add support for TP-Link LTE module
Henryk Heisig [Mon, 11 Sep 2017 15:57:34 +0000 (17:57 +0200)]
USB: serial: option: add support for TP-Link LTE module

commit 837ddc4793a69b256ac5e781a5e729b448a8d983 upstream.

This commit adds support for TP-Link LTE mPCIe module is used
in in TP-Link MR200v1, MR6400v1 and v2 routers.

Signed-off-by: Henryk Heisig <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: ftdi_sio: add id for Cypress WICED dev board
Jeffrey Chu [Fri, 8 Sep 2017 21:08:58 +0000 (21:08 +0000)]
USB: serial: ftdi_sio: add id for Cypress WICED dev board

commit a6c215e21b0dc5fe9416dce90f9acc2ea53c4502 upstream.

device IDs to ftdi_sio driver.

Signed-off-by: Jeffrey Chu <>
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoscsi: lpfc: Don't return internal MBXERR_ERROR code from probe function
Stefano Brivio [Wed, 6 Sep 2017 09:02:56 +0000 (11:02 +0200)]
scsi: lpfc: Don't return internal MBXERR_ERROR code from probe function

commit 5c756065e47dc3e84b00577bd109f0a8e69903d7 upstream.

Internal error codes happen to be positive, thus the PCI driver core
won't treat them as failure, but we do. This would cause a crash later
on as lpfc_pci_remove_one() is called (e.g. as shutdown function).

Fixes: 6d368e532168 ("[SCSI] lpfc 8.3.24: Add resource extent support")
Signed-off-by: Stefano Brivio <>
Reviewed-by: Johannes Thumshirn <>
Acked-by: Dick Kennedy <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
4 years agospi: uapi: spidev: add missing ioctl header
Baruch Siach [Sun, 10 Sep 2017 17:29:45 +0000 (20:29 +0300)]
spi: uapi: spidev: add missing ioctl header

commit a2b4a79b88b24c49d98d45a06a014ffd22ada1a4 upstream.

The SPI_IOC_MESSAGE() macro references _IOC_SIZEBITS. Add linux/ioctl.h
to make sure this macro is defined. This fixes the following build
failure of lcdproc with the musl libc:

In file included from .../sysroot/usr/include/sys/ioctl.h:7:0,
                 from hd44780-spi.c:31:
hd44780-spi.c: In function 'spi_transfer':
hd44780-spi.c:89:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
  status = ioctl(p->fd, SPI_IOC_MESSAGE(1), &xfer);

Signed-off-by: Baruch Siach <>
Signed-off-by: Mark Brown <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agotile: array underflow in setup_maxnodemem()
Dan Carpenter [Sat, 22 Jul 2017 07:33:02 +0000 (10:33 +0300)]
tile: array underflow in setup_maxnodemem()

commit 637f23abca87d26e091e0d6647ec878d97d2c6cd upstream.

My static checker correctly complains that we should have a lower bound
on "node" to prevent an array underflow.

Fixes: 867e359b97c9 ("arch/tile: core support for Tilera 32-bit chips.")
Signed-off-by: Dan Carpenter <>
Signed-off-by: Chris Metcalf <>
[bwh: Backported to 3.2: keep maxnodemem_mb as long]
Signed-off-by: Ben Hutchings <>
4 years agoLinux 3.2.96
Ben Hutchings [Sun, 26 Nov 2017 13:51:12 +0000 (13:51 +0000)]
Linux 3.2.96

4 years agomac80211: Fix null dereference in ieee80211_key_link()
Ben Hutchings [Wed, 22 Nov 2017 02:04:29 +0000 (02:04 +0000)]
mac80211: Fix null dereference in ieee80211_key_link()

Commit ef810e7c3d2a ("mac80211: accept key reinstall without changing
anything") moved the initialisation of key->sdata later in
ieee80211_key_link().  In the upstream commit fdf7cb4185b6 this was
fine, but in this version of the function there is additional code
which relies on key->sdata.  Change this to use the value that will be
(conditionally) assigned to it later.

Cc: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
4 years agomac80211: don't compare TKIP TX MIC key in reinstall prevention
Johannes Berg [Tue, 24 Oct 2017 19:12:13 +0000 (21:12 +0200)]
mac80211: don't compare TKIP TX MIC key in reinstall prevention

commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.

For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.

For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2:
 - Keep using memcmp() as we don't have crypto_memneq()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agonet: cdc_ether: fix divide by 0 on bad descriptors
Bjørn Mork [Mon, 6 Nov 2017 14:37:22 +0000 (15:37 +0100)]
net: cdc_ether: fix divide by 0 on bad descriptors

commit 2cb80187ba065d7decad7c6614e35e07aec8a974 upstream.

Setting dev->hard_mtu to 0 will cause a divide error in
usbnet_probe. Protect against devices with bogus CDC Ethernet
functional descriptors by ignoring a zero wMaxSegmentSize.

Signed-off-by: Bjørn Mork <>
Acked-by: Oliver Neukum <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: parsing code is organised differently]
Signed-off-by: Ben Hutchings <>
4 years agoInput: gtco - fix potential out-of-bound access
Dmitry Torokhov [Mon, 23 Oct 2017 23:46:00 +0000 (16:46 -0700)]
Input: gtco - fix potential out-of-bound access

commit a50829479f58416a013a4ccca791336af3c584c7 upstream.

parse_hid_report_descriptor() has a while (i < length) loop, which
only guarantees that there's at least 1 byte in the buffer, but the
loop body can read multiple bytes which causes out-of-bounds access.

Reported-by: Andrey Konovalov <>
Reviewed-by: Andrey Konovalov <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: use &device->usbdev->dev as the device for dev_err()]
Signed-off-by: Ben Hutchings <>
4 years agomedia: imon: Fix null-ptr-deref in imon_probe
Arvind Yadav [Mon, 9 Oct 2017 18:14:48 +0000 (20:14 +0200)]
media: imon: Fix null-ptr-deref in imon_probe

commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.

It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.

Signed-off-by: Arvind Yadav <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Sean Young <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
4 years agocx231xx-cards: fix NULL-deref on missing association descriptor
Johan Hovold [Thu, 21 Sep 2017 08:40:18 +0000 (05:40 -0300)]
cx231xx-cards: fix NULL-deref on missing association descriptor

commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream.

Make sure to check that we actually have an Interface Association
Descriptor before dereferencing it during probe to avoid dereferencing a

Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")

Reported-by: Andrey Konovalov <>
Signed-off-by: Johan Hovold <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: serial: console: fix use-after-free after failed setup
Johan Hovold [Wed, 4 Oct 2017 09:01:13 +0000 (11:01 +0200)]
USB: serial: console: fix use-after-free after failed setup

commit 299d7572e46f98534033a9e65973f13ad1ce9047 upstream.

Make sure to reset the USB-console port pointer when console setup fails
in order to avoid having the struct usb_serial be prematurely freed by
the console code when the device is later disconnected.

Fixes: 73e487fdb75f ("[PATCH] USB console: fix disconnection issues")
Acked-by: Greg Kroah-Hartman <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
4 years agosctp: do not peel off an assoc from one netns to another one
Xin Long [Tue, 17 Oct 2017 15:26:10 +0000 (23:26 +0800)]
sctp: do not peel off an assoc from one netns to another one

commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 upstream.

Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.

As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.

This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:


This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.

Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually

Reported-by: ChunYu Wang <>
Signed-off-by: Xin Long <>
Acked-by: Marcelo Ricardo Leitner <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Add #include <linux/nsproxy.h>
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoext4: fix fencepost in s_first_meta_bg validation
Theodore Ts'o [Wed, 15 Feb 2017 06:26:39 +0000 (01:26 -0500)]
ext4: fix fencepost in s_first_meta_bg validation

commit 2ba3e6e8afc9b6188b471f27cf2b5e3cf34e7af2 upstream.

It is OK for s_first_meta_bg to be equal to the number of block group
descriptor blocks.  (It rarely happens, but it shouldn't cause any

Fixes: 3a4b77cd47bb837b8557595ec7425f281f2ca1fe
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoext4: validate s_first_meta_bg at mount time
Eryu Guan [Thu, 1 Dec 2016 20:08:37 +0000 (15:08 -0500)]
ext4: validate s_first_meta_bg at mount time

commit 3a4b77cd47bb837b8557595ec7425f281f2ca1fe upstream.

Ralf Spenneberg reported that he hit a kernel crash when mounting a
modified ext4 image. And it turns out that kernel crashed when
calculating fs overhead (ext4_calculate_overhead()), this is because
the image has very large s_first_meta_bg (debug code shows it's
842150400), and ext4 overruns the memory in count_overhead() when
setting bitmap buffer, which is PAGE_SIZE.

  buf = get_zeroed_page(GFP_NOFS);  <=== PAGE_SIZE buffer
  blks = count_overhead(sb, i, buf);

  for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) { <=== j = 842150400
          ext4_set_bit(EXT4_B2C(sbi, s++), buf);   <=== buffer overrun

This can be reproduced easily for me by this script:

  rm -f fs.img
  mkdir -p /mnt/ext4
  fallocate -l 16M fs.img
  mke2fs -t ext4 -O bigalloc,meta_bg,^resize_inode -F fs.img
  debugfs -w -R "ssv first_meta_bg 842150400" fs.img
  mount -o loop fs.img /mnt/ext4

Fix it by validating s_first_meta_bg first at mount time, and
refusing to mount if its value exceeds the largest possible meta_bg

Reported-by: Ralf Spenneberg <>
Signed-off-by: Eryu Guan <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Andreas Dilger <>
[bwh: Backported to 3.2: open-code ext4_has_feature_meta_bg()]
Signed-off-by: Ben Hutchings <>
4 years agoInput: i8042 - add Gigabyte P57 to the keyboard reset table
Kai-Heng Feng [Fri, 15 Sep 2017 16:36:16 +0000 (09:36 -0700)]
Input: i8042 - add Gigabyte P57 to the keyboard reset table

commit 697c5d8a36768b36729533fb44622b35d56d6ad0 upstream.

Similar to other Gigabyte laptops, the touchpad on P57 requires a
keyboard reset to detect Elantech touchpad correctly.

Signed-off-by: Kai-Heng Feng <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
4 years agoKVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions...
Wanpeng Li [Thu, 14 Sep 2017 10:54:16 +0000 (03:54 -0700)]
KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously

commit 9a6e7c39810e4a8bc7fc95056cefb40583fe07ef upstream.

qemu-system-x86-8600  [004] d..1  7205.687530: kvm_entry: vcpu 2
qemu-system-x86-8600  [004] ....  7205.687532: kvm_exit: reason EXCEPTION_NMI rip 0xffffffffa921297d info ffffeb2c0e44e018 80000b0e
qemu-system-x86-8600  [004] ....  7205.687532: kvm_page_fault: address ffffeb2c0e44e018 error_code 0
qemu-system-x86-8600  [004] ....  7205.687620: kvm_try_async_get_page: gva = 0xffffeb2c0e44e018, gfn = 0x427e4e
qemu-system-x86-8600  [004] .N..  7205.687628: kvm_async_pf_not_present: token 0x8b002 gva 0xffffeb2c0e44e018
    kworker/4:2-7814  [004] ....  7205.687655: kvm_async_pf_completed: gva 0xffffeb2c0e44e018 address 0x7fcc30c4e000
qemu-system-x86-8600  [004] ....  7205.687703: kvm_async_pf_ready: token 0x8b002 gva 0xffffeb2c0e44e018
qemu-system-x86-8600  [004] d..1  7205.687711: kvm_entry: vcpu 2

After running some memory intensive workload in guest, I catch the kworker
which completes the GUP too quickly, and queues an "Page Ready" #PF exception
after the "Page not Present" exception before the next vmentry as the above
trace which will result in #DF injected to guest.

This patch fixes it by clearing the queue for "Page not Present" if "Page Ready"
occurs before the next vmentry since the GUP has already got the required page
and shadow page table has already been fixed by "Page Ready" handler.

Cc: Paolo Bonzini <>
Cc: Radim Krčmář <>
Signed-off-by: Wanpeng Li <>
Fixes: 7c90705bf2a3 ("KVM: Inject asynchronous page fault into a PV guest if page is swapped out.")
[Changed indentation and added clearing of injected. - Radim]
Signed-off-by: Radim Krčmář <>
[bwh: Backported to 3.2: Don't assign to kvm_queued_exception::injected or
Signed-off-by: Ben Hutchings <>
4 years agoKVM: SVM: Add a missing 'break' statement
Jan H. Schönherr [Tue, 5 Sep 2017 21:58:44 +0000 (23:58 +0200)]
KVM: SVM: Add a missing 'break' statement

commit 49a8afca386ee1775519a4aa80f8e121bd227dd4 upstream.

Signed-off-by: Jan H. Schönherr <>
Fixes: f6511935f424 ("KVM: SVM: Add checks for IO instructions")
Reviewed-by: David Hildenbrand <>
Signed-off-by: Radim Krčmář <>
Signed-off-by: Ben Hutchings <>
4 years agosmsc95xx: Configure pause time to 0xffff when tx flow control enabled
Nisar Sayed [Mon, 11 Sep 2017 17:43:11 +0000 (17:43 +0000)]
smsc95xx: Configure pause time to 0xffff when tx flow control enabled

commit 9c0827317f235865ae421293f8aecf6cb327a63e upstream.

Configure pause time to 0xffff when tx flow control enabled

Set pause time to 0xffff in the pause frame to indicate the
partner to stop sending the packets. When RX buffer frees up,
the device sends pause frame with pause time zero for partner to
resume transmission.

Fixes: 2f7ca802bdae ("Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
Signed-off-by: Nisar Sayed <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoInput: xpad - validate USB endpoint type during probe
Cameron Gutman [Tue, 12 Sep 2017 18:27:44 +0000 (11:27 -0700)]
Input: xpad - validate USB endpoint type during probe

commit 122d6a347329818419b032c5a1776e6b3866d9b9 upstream.

We should only see devices with interrupt endpoints. Ignore any other
endpoints that we find, so we don't send try to send them interrupt URBs
and trigger a WARN down in the USB stack.

Reported-by: Andrey Konovalov <>
Tested-by: Andrey Konovalov <>
Signed-off-by: Cameron Gutman <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
4 years agoInput: xpad - don't depend on endpoint order
Cameron Gutman [Wed, 4 Jan 2017 06:40:38 +0000 (22:40 -0800)]
Input: xpad - don't depend on endpoint order

commit c01b5e7464f0cf20936d7467c7528163c4e2782d upstream.

The order of endpoints is well defined on official Xbox pads, but
we have found at least one 3rd-party pad that doesn't follow the
standard ("Titanfall 2 Xbox One controller" 0e6f:0165).

Fortunately, we get lucky with this specific pad because it uses
endpoint addresses that differ only by direction. We know that
there are other pads out where this is not true, so let's go
ahead and fix this.

Signed-off-by: Cameron Gutman <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2:
 - Use 'fail3' label in case of failure
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoInput: xpad - add support for Xbox One controllers
Ted Mielczarek [Fri, 8 Aug 2014 18:21:59 +0000 (11:21 -0700)]
Input: xpad - add support for Xbox One controllers

commit 1a48ff81b3912be5fadae3fafde6c2f632246a4c upstream.

Xbox One controllers require an initialization message to start sending
data, so xpad_init_output becomes a required function. The Xbox One
controller does not have LEDs like the Xbox 360 controller, so that
functionality is not implemented. The format of messages controlling rumble
is currently undocumented, so rumble support is not yet implemented.

Note that Xbox One controller advertises three interfaces with the same
interface class, subclass and protocol, so we have to also match against
interface number.

Signed-off-by: Ted Mielczarek <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoInput: xpad - add a few new VID/PID combinations
Guillermo A. Amaral [Mon, 3 Dec 2012 07:26:18 +0000 (23:26 -0800)]
Input: xpad - add a few new VID/PID combinations

commit 540602a43ae5fa94064f8fae100f5ca75d4c002b upstream.

This adds VID/PID combinations for MadCatz, PDP and PowerA (new).

Removed Pelican 'TSZ' Wired Xbox 360 Controller since it's clashing with Edge
wireless Controller and I failed to confirm the PID.

Signed-off-by: "Guillermo A. Amaral B." <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
4 years agoipv6: fix typo in fib6_net_exit()
Eric Dumazet [Fri, 8 Sep 2017 22:48:47 +0000 (15:48 -0700)]
ipv6: fix typo in fib6_net_exit()

commit 32a805baf0fb70b6dbedefcd7249ac7f580f9e3b upstream.


Fixes: ba1cc08d9488 ("ipv6: fix memory leak with multiple tables during netns destruction")
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoipv6: fix memory leak with multiple tables during netns destruction
Sabrina Dubroca [Fri, 8 Sep 2017 08:26:19 +0000 (10:26 +0200)]
ipv6: fix memory leak with multiple tables during netns destruction

commit ba1cc08d9488c94cb8d94f545305688b72a2a300 upstream.

fib6_net_exit only frees the main and local tables. If another table was
created with fib6_alloc_table, we leak it when the netns is destroyed.

Fix this in the same way ip_fib_net_exit cleans up tables, by walking
through the whole hashtable of fib6_table's. We can get rid of the
special cases for local and main, since they're also part of the

    ip netns add x
    ip -net x -6 rule add from 6003:1::/64 table 100
    ip netns del x

Reported-by: Jianlin Shi <>
Fixes: 58f09b78b730 ("[NETNS][IPV6] ip6_fib - make it per network namespace")
Signed-off-by: Sabrina Dubroca <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - No need to call inetpeer_invalidate_tree()
 - Add the extra iterator variable needed by hlist_for_each_entry_safe()]
Signed-off-by: Ben Hutchings <>
4 years agogenirq: Make sparse_irq_lock protect what it should protect
Thomas Gleixner [Tue, 5 Sep 2017 08:12:20 +0000 (10:12 +0200)]
genirq: Make sparse_irq_lock protect what it should protect

commit 12ac1d0f6c3e95732d144ffa65c8b20fbd9aa462 upstream.

for_each_active_irq() iterates the sparse irq allocation bitmap. The caller
must hold sparse_irq_lock. Several code pathes expect that an active bit in
the sparse bitmap also has a valid interrupt descriptor.

Unfortunately that's not true. The (de)allocation is a two step process,
which holds the sparse_irq_lock only across the queue/remove from the radix
tree and the set/clear in the allocation bitmap.

If a iteration locks sparse_irq_lock between the two steps, then it might
see an active bit but the corresponding irq descriptor is NULL. If that is
dereferenced unconditionally, then the kernel oopses. Of course, all
iterator sites could be audited and fixed, but....

There is no reason why the sparse_irq_lock needs to be dropped between the
two steps, in fact the code becomes simpler when the mutex is held across
both and the semantics become more straight forward, so future problems of
missing NULL pointer checks in the iteration are avoided and all existing
sites are fixed in one go.

Expand the lock held sections so both operations are covered and the bitmap
and the radixtree are in sync.

Fixes: a05a900a51c7 ("genirq: Make sparse_lock a mutex")
Reported-and-tested-by: Huang Ying <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agomm/vmstat.c: fix wrong comment
SeongJae Park [Wed, 6 Sep 2017 23:24:23 +0000 (16:24 -0700)]
mm/vmstat.c: fix wrong comment

commit f113e64121ba9f4791332248b315d9f57ee33a6b upstream.

Comment for pagetypeinfo_showblockcount() is mistakenly duplicated from
pagetypeinfo_show_free()'s comment.  This commit fixes it.

Fixes: 467c996c1e19 ("Print out statistics in relation to fragmentation avoidance to /proc/pagetypeinfo")
Signed-off-by: SeongJae Park <>
Cc: Michal Hocko <>
Cc: Vlastimil Babka <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
4 years agoMIPS: BCM63XX: allow NULL clock for clk_get_rate
Jonas Gorski [Tue, 18 Jul 2017 10:17:27 +0000 (12:17 +0200)]
MIPS: BCM63XX: allow NULL clock for clk_get_rate

commit 1b495faec231980b6c719994b24044ccc04ae06c upstream.

Make the behaviour of clk_get_rate consistent with common clk's
clk_get_rate by accepting NULL clocks as parameter. Some device
drivers rely on this, and will cause an OOPS otherwise.

Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.")
Reported-by: Mathias Kresin <>
Signed-off-by: Jonas Gorski <>
Reviewed-by: Florian Fainelli <>
Cc: James Hogan <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
4 years agoMIPS: AR7: allow NULL clock for clk_get_rate
Jonas Gorski [Tue, 18 Jul 2017 10:17:26 +0000 (12:17 +0200)]
MIPS: AR7: allow NULL clock for clk_get_rate

commit 585e0e9d02a690c29932b2fc0789835c7b91d448 upstream.

Make the behaviour of clk_get_rate consistent with common clk's
clk_get_rate by accepting NULL clocks as parameter. Some device
drivers rely on this, and will cause an OOPS otherwise.

Fixes: 780019ddf02f ("MIPS: AR7: Implement clock API")
Signed-off-by: Jonas Gorski <>
Reported-by: Mathias Kresin <>
Cc: Paul Gortmaker <>
Cc: James Hogan <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
4 years agol2tp: pass tunnel pointer to ->session_create()
Guillaume Nault [Fri, 1 Sep 2017 15:58:51 +0000 (17:58 +0200)]
l2tp: pass tunnel pointer to ->session_create()

commit f026bc29a8e093edfbb2a77700454b285c97e8ad upstream.

Using l2tp_tunnel_find() in pppol2tp_session_create() and
l2tp_eth_create() is racy, because no reference is held on the
returned session. These functions are only used to implement the
->session_create callback which is run by l2tp_nl_cmd_session_create().
Therefore searching for the parent tunnel isn't necessary because
l2tp_nl_cmd_session_create() already has a pointer to it and holds a

This patch modifies ->session_create()'s prototype to directly pass the
the parent tunnel as parameter, thus avoiding searching for it in
pppol2tp_session_create() and l2tp_eth_create().

Since we have to touch the ->session_create() call in
l2tp_nl_cmd_session_create(), let's also remove the useless conditional:
we know that ->session_create isn't NULL at this point because it's
already been checked earlier in this same function.

Finally, one might be tempted to think that the removed
l2tp_tunnel_find() calls were harmless because they would return the
same tunnel as the one held by l2tp_nl_cmd_session_create() anyway.
But that tunnel might be removed and a new one created with same tunnel
Id before the l2tp_tunnel_find() call. In this case l2tp_tunnel_find()
would return the new tunnel which wouldn't be protected by the
reference held by l2tp_nl_cmd_session_create().

Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Fixes: d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agol2tp: prevent creation of sessions on terminated tunnels
Guillaume Nault [Fri, 1 Sep 2017 15:58:48 +0000 (17:58 +0200)]
l2tp: prevent creation of sessions on terminated tunnels

commit f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb upstream.

l2tp_tunnel_destruct() sets tunnel->sock to NULL, then removes the
tunnel from the pernet list and finally closes all its sessions.
Therefore, it's possible to add a session to a tunnel that is still
reachable, but for which tunnel->sock has already been reset. This can
make l2tp_session_create() dereference a NULL pointer when calling

This patch adds the .acpt_newsess field to struct l2tp_tunnel, which is
used by l2tp_tunnel_closeall() to prevent addition of new sessions to
tunnels. Resetting tunnel->sock is done after l2tp_tunnel_closeall()
returned, so that l2tp_session_add_to_tunnel() can safely take a
reference on it when .acpt_newsess is true.

The .acpt_newsess field is modified in l2tp_tunnel_closeall(), rather
than in l2tp_tunnel_destruct(), so that it benefits all tunnel removal
mechanisms. E.g. on UDP tunnels, a session could be added to a tunnel
after l2tp_udp_encap_destroy() proceeded. This would prevent the tunnel
from being removed because of the references held by this new session
on the tunnel and its socket. Even though the session could be removed
manually later on, this defeats the purpose of
commit 9980d001cec8 ("l2tp: add udp encap socket destroy handler").

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Drop changes in l2tp_tunnel_destruct(), as the assignment to tunnel->sock
   is already after the call to l2tp_tunnel_closeall()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoxfs: fix incorrect log_flushed on fsync
Amir Goldstein [Wed, 30 Aug 2017 16:23:12 +0000 (09:23 -0700)]
xfs: fix incorrect log_flushed on fsync

commit 47c7d0b19502583120c3f396c7559e7a77288a68 upstream.

When calling into _xfs_log_force{,_lsn}() with a pointer
to log_flushed variable, log_flushed will be set to 1 if:
1. xlog_sync() is called to flush the active log buffer
2. xlog_wait() is called to wait on a syncing log buffers

xfs_file_fsync() checks the value of log_flushed after
_xfs_log_force_lsn() call to optimize away an explicit
PREFLUSH request to the data block device after writing
out all the file's pages to disk.

This optimization is incorrect in the following sequence of events:

 Task A                    Task B
        [submit PREFLUSH]
                               [submit WRITE X]
                               [endio  WRITE X]
        [endio  PREFLUSH]

The write X is not guarantied to be on persistent storage
when PREFLUSH request in completed, because write A was submitted
after the PREFLUSH request, but xfs_file_fsync() of task A will
be notified of log_flushed=1 and will skip explicit flush.

If the system crashes after fsync of task A, write X may not be
present on disk after reboot.

This bug was discovered and demonstrated using Josef Bacik's
dm-log-writes target, which can be used to record block io operations
and then replay a subset of these operations onto the target device.
The test goes something like this:
- Use fsx to execute ops of a file and record ops on log device
- Every now and then fsync the file, store md5 of file and mark
  the location in the log
- Then replay log onto device for each mark, mount fs and compare
  md5 of file to stored value

Cc: Christoph Hellwig <>
Cc: Josef Bacik <>
Signed-off-by: Amir Goldstein <>
Reviewed-by: Darrick J. Wong <>
Signed-off-by: Darrick J. Wong <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoftrace: Fix selftest goto location on error
Steven Rostedt (VMware) [Fri, 1 Sep 2017 16:04:09 +0000 (12:04 -0400)]
ftrace: Fix selftest goto location on error

commit 46320a6acc4fb58f04bcf78c4c942cc43b20f986 upstream.

In the second iteration of trace_selftest_ops(), the error goto label is
wrong in the case where trace_selftest_test_global_cnt is off. In the
case of error, it leaks the dynamic ops that was allocated.

Fixes: 95950c2e ("ftrace: Add self-tests for multiple function trace users")
Signed-off-by: Steven Rostedt (VMware) <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
4 years agodriver core: bus: Fix a potential double free
Christophe JAILLET [Tue, 29 Aug 2017 19:23:49 +0000 (21:23 +0200)]
driver core: bus: Fix a potential double free

commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.

The .release function of driver_ktype is 'driver_release()'.
This function frees the container_of this kobject.

So, this memory must not be freed explicitly in the error handling path of
'bus_add_driver()'. Otherwise a double free will occur.

Signed-off-by: Christophe JAILLET <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agopowerpc: Correct instruction code for xxlor instruction
Paul Mackerras [Wed, 30 Aug 2017 04:12:24 +0000 (14:12 +1000)]
powerpc: Correct instruction code for xxlor instruction

commit 93b2d3cf3733b4060d3623161551f51ea1ab5499 upstream.

The instruction code for xxlor that commit 0016a4cf5582 ("powerpc:
Emulate most Book I instructions in emulate_step()", 2010-06-15)
added is actually the code for xxlnor.  It is used in get_vsr()
and put_vsr() and the effect of the error is that if emulate_step
is used to emulate a VSX load or store from any register other
than vsr0, the bitwise complement of the correct value will be
loaded or stored.  This corrects the error.

Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()")
Signed-off-by: Paul Mackerras <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agopowerpc/44x: Fix mask and shift to zero bug
Dan Carpenter [Fri, 25 Aug 2017 10:33:40 +0000 (13:33 +0300)]
powerpc/44x: Fix mask and shift to zero bug

commit 8d046759f6ad75824fdf7b9c9a3da0272ea9ea92 upstream.

My static checker complains that 0x00001800 >> 13 is zero. Looking at
the context, it seems like a copy and paste bug from the line below
and probably 0x3 << 13 or 0x00006000 was intended.

Fixes: 2af59f7d5c3e ("[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper")
Signed-off-by: Dan Carpenter <>
Acked-by: Benjamin Herrenschmidt <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: qla2xxx: Fix an integer overflow in sysfs code
Dan Carpenter [Wed, 30 Aug 2017 13:30:35 +0000 (16:30 +0300)]
scsi: qla2xxx: Fix an integer overflow in sysfs code

commit e6f77540c067b48dee10f1e33678415bfcc89017 upstream.

The value of "size" comes from the user.  When we add "start + size" it
could lead to an integer overflow bug.

It means we vmalloc() a lot more memory than we had intended.  I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers.  So we would get memory corruption and likely
a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().

Only root can trigger this bug.

Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
Reported-by: shqking <>
Signed-off-by: Dan Carpenter <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoqla2xxx: Add mutex around optrom calls to serialize accesses.
Chad Dupuis [Wed, 26 Feb 2014 09:14:56 +0000 (04:14 -0500)]
qla2xxx: Add mutex around optrom calls to serialize accesses.

commit 7a8ab9c840b5dff9bb70328338a86444ed1c2415 upstream.

Signed-off-by: Chad Dupuis <>
Signed-off-by: Saurav Kashyap <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoqla2xxx: Corrections to returned sysfs error codes.
Joe Carnuccio [Fri, 18 Nov 2011 17:03:13 +0000 (09:03 -0800)]
qla2xxx: Corrections to returned sysfs error codes.

commit 71dfe9e776878d9583d004edade55edc2bdac5eb upstream.

Correct the erroneous return codes introduced by the following patch:
"Return sysfs error codes appropriate to conditions".

Signed-off-by: Joe Carnuccio <>
Signed-off-by: Chad Dupuis <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: aacraid: Fix command send race condition
Brian King [Tue, 29 Aug 2017 15:00:29 +0000 (10:00 -0500)]
scsi: aacraid: Fix command send race condition

commit 1ae948fa4f00f3a2823e7cb19a3049ef27dd6947 upstream.

This fixes a potential race condition observed on Power systems.

Several places throughout the aacraid driver call aac_fib_send or
similar to send a command to the aacraid adapter, then check the return
code to determine if the command was actually sent to the adapter, then
update the phase field in the scsi command scratch pad area to track
that the firmware now owns this command.  However, there is nothing that
ensures that by the time the aac_fib_send function returns and we go to
write to the scsi command, that the command hasn't already completed and
the scsi command has been freed.  This was causing random crashes in the
TCP stack which was tracked down to be caused by memory that had been a
struct request + scsi_cmnd being now used for an skbuff. Memory
poisoning was enabled in the kernel to debug this which showed that the
last owner of the memory that had been freed was aacraid and that it was
a struct request.  The memory that was corrupted was the exact data
pattern of AAC_OWNER_FIRMWARE and it was at the same offset that aacraid
writes, which is scsicmd->SCp.phase. The patch below resolves this

Signed-off-by: Brian King <>
Tested-by: Wen Xiong <>
Reviewed-by: Dave Carroll <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2:
 - Drop changes to aac_send_hba_fib()
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agonet/mlx4_core: Make explicit conversion to 64bit value
Leon Romanovsky [Mon, 28 Aug 2017 13:38:21 +0000 (16:38 +0300)]
net/mlx4_core: Make explicit conversion to 64bit value

commit 187782eb58a89ea030731114c6ae37842a4472fe upstream.

The "lg" variable is declared as int so in all places where this variable
is used as a shift operand, the output will be int too.

This produces the following smatch warning:
drivers/net/ethernet/mellanox/mlx4/fw.c:1532 mlx4_map_cmd() warn:
should '1 << lg' be a 64 bit type?

Simple declaration of "1" to be "1ULL" will fix the issue.

Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Signed-off-by: Leon Romanovsky <>
Signed-off-by: Tariq Toukan <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
4 years agoIB/{qib, hfi1}: Avoid flow control testing for RDMA write operation
Mike Marciniszyn [Tue, 22 Aug 2017 01:26:20 +0000 (18:26 -0700)]
IB/{qib, hfi1}: Avoid flow control testing for RDMA write operation

commit 5b0ef650bd0f820e922fcc42f1985d4621ae19cf upstream.

Section of the 1.3 IBTA spec clearly says that receive
credits should never apply to RDMA write.

qib and hfi1 were doing that.  The following situation will result
in a QP hang:
- A prior SEND or RDMA_WRITE with immmediate consumed the last
  credit for a QP using RC receive buffer credits
- The prior op is acked so there are no more acks
- The peer ULP fails to post receive for some reason
- An RDMA write sees that the credits are exhausted and waits
- The peer ULP posts receive buffers
- The ULP posts a send or RDMA write that will be hung

The fix is to avoid the credit test for the RDMA write operation.

Reviewed-by: Kaike Wan <>
Signed-off-by: Mike Marciniszyn <>
Signed-off-by: Dennis Dalessandro <>
Signed-off-by: Doug Ledford <>
[bwh: Backported to 3.2:
 - Drop changes to hfi1
 - Adjust context]
Signed-off-by: Ben Hutchings <>
4 years agousb: Add device quirk for Logitech HD Pro Webcam C920-C
Dmitry Fleytman [Fri, 25 Aug 2017 07:38:35 +0000 (10:38 +0300)]
usb: Add device quirk for Logitech HD Pro Webcam C920-C

commit a1279ef74eeeb5f627f091c71d80dd7ac766c99d upstream.

Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.

Apparently model C920-C has the same issue so applying
the same quirk as well.

See aforementioned commit message for detailed explanation of the problem.

Signed-off-by: Dmitry Fleytman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agousb: quirks: add delay init quirk for Corsair Strafe RGB keyboard
Kai-Heng Feng [Wed, 16 Aug 2017 02:53:20 +0000 (10:53 +0800)]
usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard

commit de3af5bf259d7a0bfaac70441c8568ab5998d80c upstream.

Corsair Strafe RGB keyboard has trouble to initialize:

[ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
[ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
[ 6.871138] usb 3-6: can't read configurations, error -110
[ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
[ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
[ 12.246644] usb 3-6: can't read configurations, error -110
[ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
[ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
[ 17.622147] usb 3-6: can't read configurations, error -110
[ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
[ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
[ 22.997716] usb 3-6: can't read configurations, error -110

Although it may work after several times unpluging/pluging:

[ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
[ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
[ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
[ 68.337468] usb 3-6: Manufacturer: Corsair
[ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941

Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
can workaround this issue. Hence add the quirk for Corsair Strafe RGB.

Signed-off-by: Kai-Heng Feng <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoUSB: core: Avoid race of async_completed() w/ usbdev_release()
Douglas Anderson [Thu, 10 Aug 2017 22:42:22 +0000 (15:42 -0700)]
USB: core: Avoid race of async_completed() w/ usbdev_release()

commit ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 upstream.

While running reboot tests w/ a specific set of USB devices (and
slub_debug enabled), I found that once every few hours my device would
be crashed with a stack that looked like this:

[   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
[   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
[   14.012460] /1025536097, .owner_cpu: 0
[   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
[   14.012468] Hardware name: Google Kevin (DT)
[   14.012471] Call trace:
[   14.012483] [<....>] dump_backtrace+0x0/0x160
[   14.012487] [<....>] show_stack+0x20/0x28
[   14.012494] [<....>] dump_stack+0xb4/0xf0
[   14.012500] [<....>] spin_dump+0x8c/0x98
[   14.012504] [<....>] spin_bug+0x30/0x3c
[   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
[   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
[   14.012521] [<....>] __wake_up+0x2c/0x60
[   14.012528] [<....>] async_completed+0x2d0/0x300
[   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
[   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
[   14.012544] [<....>] xhci_irq+0x1314/0x1348
[   14.012548] [<....>] usb_hcd_irq+0x40/0x50
[   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
[   14.012556] [<....>] handle_irq_event+0x4c/0x7c
[   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
[   14.012564] [<....>] generic_handle_irq+0x30/0x44
[   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
[   14.012572] [<....>] gic_handle_irq+0xcc/0x18c

Investigation using kgdb() found that the wait queue that was passed
into wake_up() had been freed (it was filled with slub_debug poison).

I analyzed and instrumented the code and reproduced.  My current
belief is that this is happening:

1. async_completed() is called (from IRQ).  Moves "as" onto the
   completed list.
2. On another CPU, proc_reapurbnonblock_compat() calls
   async_getcompleted().  Blocks on spinlock.
3. async_completed() releases the lock; keeps running; gets blocked
   midway through wake_up().
4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
   lock; removes "as" from completed list and frees it.
5. usbdev_release() is called.  Frees "ps".
6. async_completed() finally continues running wake_up().  ...but
   wake_up() has a pointer to the freed "ps".

The instrumentation that led me to believe this was based on adding
some trace_printk() calls in a select few functions and then using
kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
below I cheated a little bit and added a udelay(1000) in
async_completed() after releasing the spinlock because I wanted it to
trigger quicker):

<...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
<...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200

To fix this problem we can just move the wake_up() under the ps->lock.
There should be no issues there that I'm aware of.

Signed-off-by: Douglas Anderson <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
4 years agomedia: em28xx: calculate left volume level correctly
Colin Ian King [Tue, 22 Aug 2017 14:21:20 +0000 (10:21 -0400)]
media: em28xx: calculate left volume level correctly

commit 801e3659bf2c87c31b7024087d61e89e172b5651 upstream.

The calculation of the left volume looks suspect, the value of
0x1f - ((val << 8) & 0x1f) is always 0x1f. The debug prior to the
assignment of value[1] prints the left volume setting using the
calculation 0x1f - (val >> 8) & 0x1f which looks correct to me.
Fix the left volume by using the correct expression as used in
the debug.

Detected by CoverityScan, CID#146140 ("Wrong operator used")

Fixes: 850d24a5a861 ("[media] em28xx-alsa: add mixer support for AC97 volume controls")

Signed-off-by: Colin Ian King <>
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agomedia: lirc_zilog: driver only sends LIRCCODE
Sean Young [Thu, 3 Aug 2017 21:42:28 +0000 (17:42 -0400)]
media: lirc_zilog: driver only sends LIRCCODE

commit 89d8a2cc51d1f29ea24a0b44dde13253141190a0 upstream.

This driver cannot send pulse, it only accepts driver-dependent codes.

Signed-off-by: Sean Young <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agomedia: uvcvideo: Prevent heap overflow when accessing mapped controls
Guenter Roeck [Tue, 8 Aug 2017 12:56:21 +0000 (08:56 -0400)]
media: uvcvideo: Prevent heap overflow when accessing mapped controls

commit 7e09f7d5c790278ab98e5f2c22307ebe8ad6e8ba upstream.

The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer

Originally-from: Richard Simmons <>

Signed-off-by: Guenter Roeck <>
Reviewed-by: Laurent Pinchart <>
Signed-off-by: Hans Verkuil <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
4 years agoblock: Relax a check in blk_start_queue()
Bart Van Assche [Thu, 17 Aug 2017 20:12:44 +0000 (13:12 -0700)]
block: Relax a check in blk_start_queue()

commit 4ddd56b003f251091a67c15ae3fe4a5c5c5e390a upstream.

Calling blk_start_queue() from interrupt context with the queue
lock held and without disabling IRQs, as the skd driver does, is
safe. This patch avoids that loading the skd driver triggers the
following warning:

WARNING: CPU: 11 PID: 1348 at block/blk-core.c:283 blk_start_queue+0x84/0xa0
RIP: 0010:blk_start_queue+0x84/0xa0
Call Trace:
 skd_unquiesce_dev+0x12a/0x1d0 [skd]
 skd_complete_internal+0x1e7/0x5a0 [skd]
 skd_complete_other+0xc2/0xd0 [skd]
 skd_isr_completion_posted.isra.30+0x2a5/0x470 [skd]
 skd_isr+0x14f/0x180 [skd]

Fixes: commit a038e2536472 ("[PATCH] blk_start_queue() must be called with irq disabled - add warning")
Signed-off-by: Bart Van Assche <>
Cc: Paolo 'Blaisorblade' Giarrusso <>
Cc: Andrew Morton <>
Cc: Christoph Hellwig <>
Cc: Hannes Reinecke <>
Cc: Johannes Thumshirn <>
Signed-off-by: Jens Axboe <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agodrm/ttm: Fix accounting error when fail to get pages for pool
Xiangliang.Yu [Wed, 16 Aug 2017 06:25:51 +0000 (14:25 +0800)]
drm/ttm: Fix accounting error when fail to get pages for pool

commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.

When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.

Signed-off-by: Xiangliang.Yu <>
Reviewed-by: Christian König <>
Reviewed-by: Monk Liu <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
4 years agocs5536: add support for IDE controller variant
Andrey Korolyov [Thu, 10 Aug 2017 10:21:14 +0000 (13:21 +0300)]
cs5536: add support for IDE controller variant

commit 591b6bb605785c12a21e8b07a08a277065b655a5 upstream.

Several legacy devices such as Geode-based Cisco ASA appliances
and DB800 development board do possess CS5536 IDE controller
with different PCI id than existing one. Using pata_generic is
not always feasible as at least DB800 requires MSR quirk from
pata_cs5536 to be used with vendor firmware.

Signed-off-by: Andrey Korolyov <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: mac_esp: Fix PIO transfers for MESSAGE IN phase
Finn Thain [Fri, 4 Aug 2017 05:43:19 +0000 (01:43 -0400)]
scsi: mac_esp: Fix PIO transfers for MESSAGE IN phase

commit 7640d91d285893a5cf1e62b2cd00f0884c401d93 upstream.

When in MESSAGE IN phase, the ESP device does not automatically
acknowledge each byte that is transferred by PIO. The mac_esp driver
neglects to explicitly ack them, which causes a timeout during messages
larger than one byte (e.g. tag bytes during reconnect). Fix this with an
ESP_CMD_MOK command after each byte.

The MESSAGE IN phase is also different in that each byte transferred
raises ESP_INTR_FDONE. So don't exit the transfer loop for this interrupt,
for this phase.

That resolves the "Reconnect IRQ2 timeout" error on those Macs which use
PIO transfers instead of PDMA. This patch also improves on the weak tests
for unexpected interrupts and phase changes during PIO transfers.

Tested-by: Stan Johnson <>
Fixes: 02507a80b35e ("[PATCH] [SCSI] mac_esp: fix PIO mode, take 2")
Signed-off-by: Finn Thain <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response
Steffen Maier [Fri, 28 Jul 2017 10:30:57 +0000 (12:30 +0200)]
scsi: zfcp: trace HBA FSF response by default on dismiss or timedout late response

commit fdb7cee3b9e3c561502e58137a837341f10cbf8b upstream.

At the default trace level, we only trace unsuccessful events including
FSF responses.

zfcp_dbf_hba_fsf_response() only used protocol status and FSF status to
decide on an unsuccessful response. However, this is only one of multiple
possible sources determining a failed struct zfcp_fsf_req.

An FSF request can also "fail" if its response runs into an ERP timeout
or if it gets dismissed because a higher level recovery was triggered
[trace tags "erscf_1" or "erscf_2" in zfcp_erp_strategy_check_fsfreq()].
FSF requests with ERP timeout are:
One example is slow queue processing which can cause follow-on errors,
In order to see the root cause, we need to see late responses even if the
channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.
Example trace records formatted with zfcpdbf from the s390-tools package:

Timestamp      : ...
Area           : REC
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : fcegpf1
LUN            : 0xffffffffffffffff
WWPN           : 0x<WWPN>
D_ID           : 0x00<D_ID>
Adapter status : 0x5400050b
Port status    : 0x41200000
LUN status     : 0x00000000
Ready count    : 0x00000001
Running count  : 0x...
Timestamp      : ... 30 seconds later
Area           : REC
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 2
Tag            : erscf_2
LUN            : 0xffffffffffffffff
WWPN           : 0x<WWPN>
D_ID           : 0x00<D_ID>
Adapter status : 0x5400050b
Port status    : 0x41200000
LUN status     : 0x00000000
Request ID     : 0x<request_ID>
ERP status     : 0x10000000 ZFCP_STATUS_ERP_TIMEDOUT
ERP step       : 0x0800 ZFCP_ERP_STEP_PORT_OPENING
ERP count      : 0x00
Timestamp      : ... later than previous record
Area           : HBA
Subarea        : 00
Level          : 5 > default level => 3 <= default level
Exception      : -
CPU ID         : 00
Caller         : ...
Record ID      : 1
Tag            : fs_qtcb => fs_rerr
Request ID     : 0x<request_ID>
Request status : 0x00001010 ZFCP_STATUS_FSFREQ_DISMISSED
FSF cmnd       : 0x00000005
FSF sequence no: 0x...
FSF issued     : ... > 30 seconds ago
FSF stat       : 0x00000000 FSF_GOOD
FSF stat qual  : 00000000 00000000 00000000 00000000
Prot stat      : 0x00000001 FSF_PROT_GOOD
Prot stat qual : 00000000 00000000 00000000 00000000
Port handle    : 0x...
LUN handle     : 0x00000000
QTCB log length: ...
QTCB log info  : ...

In case of problems detecting that new responses are waiting on the input
queue, we sooner or later trigger adapter recovery due to an FSF request
timeout (trace tag "fsrth_1").
FSF requests with FSF request timeout are:
typically FSF_QTCB_ABORT_FCP_CMND; but theoretically also
FSF_QTCB_FCP_CMND for task management function (LUN / target reset).
One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
because the channel filled in the response via DMA into the request's QTCB.

In a theroretical case, inject code can create an erroneous FSF request
on purpose. If data router is enabled, it uses deferred error reporting.
A READ SCSI command can succeed with FSF_PROT_GOOD, FSF_GOOD, and
SAM_STAT_GOOD. But on writing the read data to host memory via DMA,
it can still fail, e.g. if an intentionally wrong scatter list does not
provide enough space. Rather than getting an unsuccessful response,
we get a QDIO activate check which in turn triggers adapter recovery.
One or more pending requests can meanwhile have FSF_PROT_GOOD and FSF_GOOD
because the channel filled in the response via DMA into the request's QTCB.
Example trace records formatted with zfcpdbf from the s390-tools package:

Timestamp      : ...
Area           : HBA
Subarea        : 00
Level          : 6 > default level => 3 <= default level
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : fs_norm => fs_rerr
Request ID     : 0x<request_ID2>
Request status : 0x00001010 ZFCP_STATUS_FSFREQ_DISMISSED
FSF cmnd       : 0x00000001
FSF sequence no: 0x...
FSF issued     : ...
FSF stat       : 0x00000000 FSF_GOOD
FSF stat qual  : 00000000 00000000 00000000 00000000
Prot stat      : 0x00000001 FSF_PROT_GOOD
Prot stat qual : ........ ........ 00000000 00000000
Port handle    : 0x...
LUN handle     : 0x...
Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 3
Exception      : -
CPU ID         : ..
Caller         : ...
Record ID      : 1
Tag            : rsl_err
Request ID     : 0x<request_ID2>
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x000e0000 DID_TRANSPORT_DISRUPTED
SCSI retries   : 0x00
SCSI allowed   : 0x05
SCSI scribble  : 0x<request_ID2>
SCSI opcode    : 28... Read(10)
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000000 00000000
                                         ^^ SAM_STAT_GOOD
                 00000000 00000000

Only with luck in both above cases, we could see a follow-on trace record
of an unsuccesful event following a successful but late FSF response with
FSF_PROT_GOOD and FSF_GOOD. Typically this was the case for I/O requests
resulting in a SCSI trace record "rsl_err" with DID_TRANSPORT_DISRUPTED
[On ZFCP_STATUS_FSFREQ_DISMISSED, zfcp_fsf_protstatus_eval() sets
ZFCP_STATUS_FSFREQ_ERROR seen by the request handler functions as failure].
However, the reason for this follow-on trace was invisible because the
corresponding HBA trace record was missing at the default trace level
(by default hidden records with tags "fs_norm", "fs_qtcb", or "fs_open").

On adapter recovery, after we had shut down the QDIO queues, we perform
unsuccessful pseudo completions with flag ZFCP_STATUS_FSFREQ_DISMISSED
for each pending FSF request in zfcp_fsf_req_dismiss_all().
In order to find the root cause, we need to see all pseudo responses even
if the channel presented them successfully with FSF_PROT_GOOD and FSF_GOOD.

Therefore, check zfcp_fsf_req.status for ZFCP_STATUS_FSFREQ_DISMISSED
or ZFCP_STATUS_FSFREQ_ERROR and trace with a new tag "fs_rerr".

It does not matter that there are numerous places which set
ZFCP_STATUS_FSFREQ_ERROR after the location where we trace an FSF response
early. These cases are based on protocol status != FSF_PROT_GOOD or
== FSF_PROT_FSF_STATUS_PRESENTED and are thus already traced by default
as trace tag "fs_perr" or "fs_ferr" respectively.

NB: The trace record with tag "fssrh_1" for status read buffers on dismiss
all remains. zfcp_fsf_req_complete() handles this and returns early.
All other FSF request types are handled separately and as described above.

Signed-off-by: Steffen Maier <>
Fixes: 8a36e4532ea1 ("[SCSI] zfcp: enhancement of zfcp debug features")
Fixes: 2e261af84cdb ("[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levels")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records
Steffen Maier [Fri, 28 Jul 2017 10:30:56 +0000 (12:30 +0200)]
scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace records

commit 12c3e5754c8022a4f2fd1e9f00d19e99ee0d3cc1 upstream.

If the FCP_RSP UI has optional parts (FCP_SNS_INFO or FCP_RSP_INFO) and
thus does not fit into the fsp_rsp field built into a SCSI trace record,
trace the full FCP_RSP UI with all optional parts as payload record
instead of just FCP_SNS_INFO as payload and
a 1 byte RSP_INFO_CODE part of FCP_RSP_INFO built into the SCSI record.

That way we would also get the full FCP_SNS_INFO in case a
target would ever send more than

The mandatory part of FCP_RSP IU is only 24 bytes.
PAYload costs at least one full PAY record of 256 bytes anyway.
We cap to the hardware response size which is only FSF_FCP_RSP_SIZE==128.
So we can just put the whole FCP_RSP IU with any optional parts into
PAYload similarly as we do for SAN PAY since v4.9 commit aceeffbb59bb
("zfcp: trace full payload of all SAN records (req,resp,iels)").
This does not cause any additional trace records wasting memory.

Decoded trace records were confusing because they showed a hard-coded
sense data length of 96 even if the FCP_RSP_IU field FCP_SNS_LEN showed
actually less.

Since the same commit, we set pl_len for SAN traces to the full length of a
request/response even if we cap the corresponding trace.
In contrast, here for SCSI traces we set pl_len to the pre-computed
length of FCP_RSP IU considering SNS_LEN or RSP_LEN if valid.
Nonetheless we trace a hardcoded payload of length FSF_FCP_RSP_SIZE==128
if there were optional parts.
This makes it easier for the zfcpdbf tool to format only the relevant
part of the long FCP_RSP UI buffer. And any trailing information is still
available in the payload trace record just in case.

Rename the payload record tag from "fcp_sns" to "fcp_riu" to make the new
content explicit to zfcpdbf which can then pick a suitable field name such
as "FCP rsp IU all:" instead of "Sense info :"
Also, the same zfcpdbf can still be backwards compatible with "fcp_sns".

Old example trace record before this fix, formatted with the tool zfcpdbf
from s390-tools:

Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 3
Exception      : -
CPU id         : ..
Caller         : 0x...
Record id      : 1
Tag            : rsl_err
Request id     : 0x<request_id>
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x00000002
SCSI retries   : 0x00
SCSI allowed   : 0x05
SCSI scribble  : 0x<request_id>
SCSI opcode    : 00000000 00000000 00000000 00000000
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000202 00000000
                 00000020 00000000
Sense info     : 70000600 00000018 00000000 29000000
                 00000400 00000000 00000000 00000000
                 00000000 00000000 00000000 00000000<==superfluous
                 00000000 00000000 00000000 00000000<==superfluous
                 00000000 00000000 00000000 00000000<==superfluous
                 00000000 00000000 00000000 00000000<==superfluous

New example trace records with this fix:

Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 3
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : rsl_err
Request ID     : 0x<request_id>
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x00000002
SCSI retries   : 0x00
SCSI allowed   : 0x03
SCSI scribble  : 0x<request_id>
SCSI opcode    : a30c0112 00000000 02000000 00000000
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000a02 00000200
                 00000020 00000000
FCP rsp IU len : 56
FCP rsp IU all : 00000000 00000000 00000a02 00000200
                 00000020 00000000 70000500 00000018
                 00000000 240000cb 00011100 00000000
                 00000000 00000000

Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : lr_okay
Request ID     : 0x<request_id>
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x00000000
SCSI retries   : 0x00
SCSI allowed   : 0x05
SCSI scribble  : 0x<request_id>
SCSI opcode    : <CDB of unrelated SCSI command passed to eh handler>
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000100 00000000
                 00000000 00000008
FCP rsp IU len : 32
FCP rsp IU all : 00000000 00000000 00000100 00000000
                 00000000 00000008 00000000 00000000

Signed-off-by: Steffen Maier <>
Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: fix missing trace records for early returns in TMF eh handlers
Steffen Maier [Fri, 28 Jul 2017 10:30:55 +0000 (12:30 +0200)]
scsi: zfcp: fix missing trace records for early returns in TMF eh handlers

commit 1a5d999ebfc7bfe28deb48931bb57faa8e4102b6 upstream.

For problem determination we need to see that we were in scsi_eh
as well as whether and why we were successful or not.

The following commits introduced new early returns without adding
a trace record:

v2.6.35 commit a1dbfddd02d2
("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
on fc_block_scsi_eh() returning != 0 which is FAST_IO_FAIL,

v2.6.30 commit 63caf367e1c9
("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
on not having gotten an FSF request after the maximum number of retry
attempts and thus could not issue a TMF and has to return FAILED.

Signed-off-by: Steffen Maier <>
Fixes: a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
Fixes: 63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA
Steffen Maier [Fri, 28 Jul 2017 10:30:54 +0000 (12:30 +0200)]
scsi: zfcp: fix passing fsf_req to SCSI trace on TMF to correlate with HBA

commit 9fe5d2b2fd30aa8c7827ec62cbbe6d30df4fe3e3 upstream.

Without this fix we get SCSI trace records on task management functions
which cannot be correlated to HBA trace records because all fields
related to the FSF request are empty (zero).
Also, the FCP_RSP_IU is missing as well as any sense data if available.

This was caused by v2.6.14 commit 8a36e4532ea1 ("[SCSI] zfcp: enhancement
of zfcp debug features") introducing trace records for TMFs but
hard coding NULL for a possibly existing TMF FSF request.
The scsi_cmnd scribble is also zero or unrelated for the TMF request
so it also could not lookup a suitable FSF request from there.

A broken example trace record formatted with zfcpdbf from the s390-tools

Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : lr_fail
Request ID     : 0x0000000000000000
                   ^^^^^^^^^^^^^^^^ no correlation to HBA record
SCSI ID        : 0x<scsitarget>
SCSI LUN       : 0x<scsilun>
SCSI result    : 0x000e0000
SCSI retries   : 0x00
SCSI allowed   : 0x05
SCSI scribble  : 0x0000000000000000
SCSI opcode    : 2a000017 3bb80000 08000000 00000000
FCP rsp inf cod: 0x00
                   ^^ no TMF response
FCP rsp IU     : 00000000 00000000 00000000 00000000
                 00000000 00000000
                 ^^^^^^^^^^^^^^^^^ no interesting FCP_RSP_IU
Sense len      : ...
^^^^^^^^^^^^^^^^^^^^ no sense data length
Sense info     : ...
^^^^^^^^^^^^^^^^^^^^ no sense data content, even if present

There are some true cases where we really do not have an FSF request:
"rsl_fai" from zfcp_dbf_scsi_fail_send() called for early
returns / completions in zfcp_scsi_queuecommand(),
"abrt_or", "abrt_bl", "abrt_ru", "abrt_ar" from
zfcp_scsi_eh_abort_handler() where we did not get as far,
"lr_nres", "tr_nres" from zfcp_task_mgmt_function() where we're
successful and do not need to do anything because adapter stopped.
For these cases it's correct to pass NULL for fsf_req to _zfcp_dbf_scsi().

Signed-off-by: Steffen Maier <>
Fixes: 8a36e4532ea1 ("[SCSI] zfcp: enhancement of zfcp debug features")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records
Steffen Maier [Fri, 28 Jul 2017 10:30:53 +0000 (12:30 +0200)]
scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records

commit 975171b4461be296a35e83ebd748946b81cf0635 upstream.

v4.9 commit aceeffbb59bb ("zfcp: trace full payload of all SAN records
(req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750a884
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
necessary for problem determination, e.g. to see the
currently active zone set during automatic port scan.

While it already saves space by not dumping any empty residual entries
of the large successful GPN_FT response (4 pages), there are seldom cases
where the GPN_FT response is unsuccessful and likely does not have
FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
We typically see such case for an initiator WWPN, which is not in any zone.

Cap unsuccessful responses to at least the actual basic CT_IU response
plus whatever fits the SAN trace record built-in "payload" buffer
just in case there's trailing information
of which we would at least see the existence and its beginning.

In order not to erroneously cap successful responses, we need to swap
calling the trace function and setting the CT / ELS status to success (0).

Example trace record pair formatted with zfcpdbf:

Timestamp      : ...
Area           : SAN
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : fssct_1
Request ID     : 0x<request_id>
Destination ID : 0x00fffffc
SAN req short  : 01000000 fc020000 01720ffc 00000000
SAN req length : 20
Timestamp      : ...
Area           : SAN
Subarea        : 00
Level          : 1
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 2
Tag            : fsscth2
Request ID     : 0x<request_id>
Destination ID : 0x00fffffc
SAN resp short : 01000000 fc020000 80010000 00090700
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
SAN resp length: 16384
San resp info  : 01000000 fc020000 80010000 00090700
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]
                 00000000 00000000 00000000 00000000 [trailing info]

The fix saves all but one of the previously associated 64 PAYload trace
record chunks of size 256 bytes each.

Signed-off-by: Steffen Maier <>
Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path
Benjamin Block [Fri, 28 Jul 2017 10:30:52 +0000 (12:30 +0200)]
scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path

commit a099b7b1fc1f0418ab8d79ecf98153e1e134656e upstream.

Up until now zfcp would just ignore the FCP_RESID_OVER flag in the FCP
response IU. When this flag is set, it is possible, in regards to the
FCP standard, that the storage-server processes the command normally, up
to the point where data is missing and simply ignores those.

In this case no CHECK CONDITION would be set, and because we ignored the
FCP_RESID_OVER flag we resulted in at least a data loss or even
-corruption as a follow-up error, depending on how the
applications/layers on top behave. To prevent this, we now set the
host-byte of the corresponding scsi_cmnd to DID_ERROR.

Other storage-behaviors, where the same condition results in a CHECK
CONDITION set in the answer, don't need to be changed as they are
handled in the mid-layer already.

Following is an example trace record decoded with zfcpdbf from the
s390-tools package. We forcefully injected a fc_dl which is one byte too

Timestamp      : ...
Area           : SCSI
Subarea        : 00
Level          : 3
Exception      : -
CPU ID         : ..
Caller         : 0x...
Record ID      : 1
Tag            : rsl_err
Request ID     : 0x...
SCSI ID        : 0x...
SCSI LUN       : 0x...
SCSI result    : 0x00070000
SCSI retries   : 0x..
SCSI allowed   : 0x..
SCSI scribble  : 0x...
SCSI opcode    : 2a000000 00000000 08000000 00000000
FCP rsp inf cod: 0x00
FCP rsp IU     : 00000000 00000000 00000400 00000001
                 00000000 00000000

As of now, we don't actively handle to possibility that a response IU
has both flags - FCP_RESID_OVER and FCP_RESID_UNDER - set at once.

Reported-by: Luke M. Hopkins <>
Reviewed-by: Steffen Maier <>
Fixes: 553448f6c483 ("[SCSI] zfcp: Message cleanup")
Fixes: ea127f975424 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agoscsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled
Steffen Maier [Fri, 28 Jul 2017 10:30:51 +0000 (12:30 +0200)]
scsi: zfcp: fix queuecommand for scsi_eh commands when DIX enabled

commit 71b8e45da51a7b64a23378221c0a5868bd79da4f upstream.

Since commit db007fc5e20c ("[SCSI] Command protection operation"),
scsi_eh_prep_cmnd() saves scmd->prot_op and temporarily resets it to
Other FCP LLDDs such as qla2xxx and lpfc shield their queuecommand()
to only access any of scsi_prot_sg...() if
(scsi_get_prot_op(cmd) != SCSI_PROT_NORMAL).

Do the same thing for zfcp, which introduced DIX support with
commit ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for

Otherwise, TUR SCSI commands as part of scsi_eh likely fail in zfcp,
because the regular SCSI command with DIX protection data, that scsi_eh
re-uses in scsi_send_eh_cmnd(), of course still has
(scsi_prot_sg_count() != 0) and so zfcp sends down bogus requests to the
FCP channel hardware.

This causes scsi_eh_test_devices() to have (finish_cmds == 0)
[not SCSI device is online or not scsi_eh_tur() failed]
so regular SCSI commands, that caused / were affected by scsi_eh,
are moved to work_q and scsi_eh_test_devices() itself returns false.
In turn, it unnecessarily escalates in our case in scsi_eh_ready_devs()
beyond host reset to finally scsi_eh_offline_sdevs()
which sets affected SCSI devices offline with the following kernel message:

"kernel: sd H:0:T:L: Device offlined - not ready after error recovery"

Signed-off-by: Steffen Maier <>
Fixes: ef3eb71d8ba4 ("[SCSI] zfcp: Introduce experimental support for DIF/DIX")
Reviewed-by: Benjamin Block <>
Signed-off-by: Benjamin Block <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Ben Hutchings <>
4 years agox86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps
Andy Lutomirski [Tue, 1 Aug 2017 14:11:35 +0000 (07:11 -0700)]
x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps

commit 9584d98bed7a7a904d0702ad06bbcc94703cb5b4 upstream.

In ELF_COPY_CORE_REGS, we're copying from the current task, so
accessing thread.fsbase and thread.gsbase makes no sense.  Just read
the values from the CPU registers.

In practice, the old code would have been correct most of the time
simply because thread.fsbase and thread.gsbase usually matched the
CPU registers.

Signed-off-by: Andy Lutomirski <>
Cc: Borislav Petkov <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Chang Seok <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Josh Poimboeuf <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agodlm: avoid double-free on error path in dlm_device_{register,unregister}
Edwin Török [Thu, 3 Aug 2017 09:30:06 +0000 (10:30 +0100)]
dlm: avoid double-free on error path in dlm_device_{register,unregister}

commit 55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.

Can be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):
 # seq 1 100 | xargs -P0 -n1 dlm_tool join
 # seq 1 100 | xargs -P0 -n1 dlm_tool leave

misc_register fails due to duplicate sysfs entry, which causes
dlm_device_register to free ls->
In dlm_device_deregister the name was freed again, causing memory

According to the comment in dlm_device_deregister the name should've been
set to NULL when registration fails,
so this patch does that.

sysfs: cannot create duplicate filename '/dev/char/10:1'
------------[ cut here ]------------
warning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70
modules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
btusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi
snd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic
snd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec
cryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep
iwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw
cfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore
sunrpc parport_pc ppdev lp parport autofs4 i915 psmouse
 e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci
pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video
cpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic
hardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012
task: ffff96b0cbabe140 task.stack: ffffb199027d0000
rip: 0010:sysfs_warn_dup+0x56/0x70
rsp: 0018:ffffb199027d3c58 eflags: 00010282
rax: 0000000000000038 rbx: ffff96b0e2c49158 rcx: 0000000000000006
rdx: 0000000000000000 rsi: 0000000000000086 rdi: ffff96b15e24dcc0
rbp: ffffb199027d3c70 r08: 0000000000000001 r09: 0000000000000721
r10: ffffb199027d3c00 r11: 0000000000000721 r12: ffffb199027d3cd1
r13: ffff96b1592088f0 r14: 0000000000000001 r15: ffffffffffffffef
fs:  00007f78069c0700(0000) gs:ffff96b15e240000(0000)
cs:  0010 ds: 0000 es: 0000 cr0: 0000000080050033
cr2: 000000178625ed28 cr3: 0000000091d3e000 cr4: 00000000001406e0
call trace:
 ? snprintf+0x45/0x70
 device_write+0x6a8/0x790 [dlm]
 ? apparmor_file_permission+0x1a/0x20
 ? security_file_permission+0x3b/0xc0
 ? sys_fcntl+0x5d/0xb0
rip: 0033:0x7f78083454bd
rsp: 002b:00007f78069bbd30 eflags: 00000293 orig_rax: 0000000000000001
rax: ffffffffffffffda rbx: 0000000000000006 rcx: 00007f78083454bd
rdx: 000000000000009c rsi: 00007f78069bee00 rdi: 0000000000000005
rbp: 00007f77f8000a20 r08: 000000000000fcf0 r09: 0000000000000032
r10: 0000000000000024 r11: 0000000000000293 r12: 00007f78069bde00
r13: 00007f78069bee00 r14: 000000000000000a r15: 00007f78069bbd70
code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8
ff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89
df e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84
---[ end trace 40412246357cc9e0 ]---

dlm: 59f24629-ae39-44e2-9030-397ebc2eda26: leaving the lockspace group...
bug: unable to handle kernel null pointer dereference at 0000000000000001
ip: [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
pgd 0
oops: 0000 [#1] smp
modules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6
nf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod
aesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul
glue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss
oid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4
hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too
serio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata
scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6
cpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1
hardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017
task: ffff880002410000 ti: ffff88000243c000 task.ti: ffff88000243c000
rip: e030:[<ffffffff811a3b4a>] [<ffffffff811a3b4a>]
rsp: e02b:ffff88000243fd90 eflags: 00010202
rax: 0000000000000000 rbx: ffff8800029864d0 rcx: 000000000007b36c
rdx: 000000000007b36b rsi: 00000000024000c0 rdi: ffff880036801c00
rbp: ffff88000243fdc0 r08: 0000000000018880 r09: 0000000000000054
r10: 000000000000004a r11: ffff880034ace6c0 r12: 00000000024000c0
r13: ffff880036801c00 r14: 0000000000000001 r15: ffffffff8118dcc2
fs: 00007f0ab77548c0(0000) gs:ffff880036e00000(0000) knlgs:0000000000000000
cs: e033 ds: 0000 es: 0000 cr0: 0000000080050033
cr2: 0000000000000001 cr3: 000000000332d000 cr4: 0000000000040660
ffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0
ffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2
ffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90
call trace:
[<ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140
[<ffffffff8118dcc2>] anon_vma_fork+0x92/0x140
[<ffffffff8107033e>] copy_process+0xcae/0x1a80
[<ffffffff8107128b>] _do_fork+0x8b/0x2d0
[<ffffffff81071579>] sys_clone+0x19/0x20
[<ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71
] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80
00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c
06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63
rip [<ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
rsp <ffff88000243fd90>
cr2: 0000000000000001
--[ end trace 70cb9fd1b164a0e8 ]--

Signed-off-by: Edwin Török <>
Signed-off-by: David Teigland <>
Signed-off-by: Ben Hutchings <>
4 years agoPCI: shpchp: Enable bridge bus mastering if MSI is enabled
Aleksandr Bezzubikov [Tue, 18 Jul 2017 14:12:25 +0000 (17:12 +0300)]
PCI: shpchp: Enable bridge bus mastering if MSI is enabled

commit 48b79a14505349a29b3e20f03619ada9b33c4b17 upstream.

An SHPC may generate MSIs to notify software about slot or controller
events (SHPC spec r1.0, sec 4.7).  A PCI device can only generate an MSI if
it has bus mastering enabled.

Enable bus mastering if the bridge contains an SHPC that uses MSI for event

Signed-off-by: Aleksandr Bezzubikov <>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <>
Reviewed-by: Marcel Apfelbaum <>
Acked-by: Michael S. Tsirkin <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
4 years agopowerpc/mm: Fix check of multiple 16G pages from device tree
Rui Teng [Thu, 12 Jan 2017 09:09:06 +0000 (17:09 +0800)]
powerpc/mm: Fix check of multiple 16G pages from device tree

commit 23493c121912a39f0262e0dbeb236e1d39efa4d5 upstream.

The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.

Fixes: 4792adbac9eb ("powerpc: Don't use a 16G page if beyond mem= limits")
Signed-off-by: Rui Teng <>
Tested-by: Anshuman Khandual <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
4 years agofcntl: Don't use ambiguous SIG_POLL si_codes
Eric W. Biederman [Thu, 29 Jun 2017 14:28:50 +0000 (09:28 -0500)]
fcntl: Don't use ambiguous SIG_POLL si_codes

commit d08477aa975e97f1dc64c0ae59cebf98520456ce upstream.

We have a weird and problematic intersection of features that when
they all come together result in ambiguous siginfo values, that
we can not support properly.

- Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.

- Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
  that imply they are signal specific si_codes and using the
  aforementioned arbitrary signal to deliver them.

- Supporting injection of arbitrary siginfo values for debugging and

The result is that just looking at siginfo si_codes of 1 to 6 are
ambigious.  It could either be a signal specific si_code or it could
be a generic si_code.

For most of the kernel this is a non-issue but for sending signals
with siginfo it is impossible to play back the kernel signals and
get the same result.

Strictly speaking when the si_code was changed from SI_SIGIO to
POLL_IN and friends between 2.2 and 2.4 this functionality was not
ambiguous, as only real time signals were supported.  Before 2.4 was
released the kernel began supporting siginfo with non realtime signals
so they could give details of why the signal was sent.

The result is that if F_SETSIG is set to one of the signals with signal
specific si_codes then user space can not know why the signal was sent.

I grepped through a bunch of userspace programs using debian code
search to get a feel for how often people choose a signal that results
in an ambiguous si_code.  I only found one program doing so and it was
using SIGCHLD to test the F_SETSIG functionality, and did not appear
to be a real world usage.

Therefore the ambiguity does not appears to be a real world problem in
practice.  Remove the ambiguity while introducing the smallest chance
of breakage by changing the si_code to SI_SIGIO when signals with
signal specific si_codes are targeted.

Fixes: v2.3.40 -- Added support for queueing non-rt signals
Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
Signed-off-by: "Eric W. Biederman" <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>