6 years agorcu: Correctly handle non-empty Tiny RCU callback list with none ready
Paul E. McKenney [Mon, 11 May 2015 18:13:05 +0000 (11:13 -0700)]
rcu: Correctly handle non-empty Tiny RCU callback list with none ready

commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream.

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

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

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

commit 76e838c9f7765f9a6205b4d558d75a66104bc60d upstream.

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

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

commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.

Since we are messing with state in the worker.

v2: drop the changes in the mst worker

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

commit 8687634b7908c42eb700e0469e110e02833611d1 upstream.

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

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

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

commit d079abd181950a44cdf31daafd1662388a6c4d2e upstream.

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

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

commit 12c350050538c7dc779c083b7342bfd20f74949c upstream.

WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than

Signed-off-by: Axel Lin <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8903: Fix define for WM8903_VMID_RES_250K
Axel Lin [Mon, 11 May 2015 01:04:06 +0000 (09:04 +0800)]
ASoC: wm8903: Fix define for WM8903_VMID_RES_250K

commit ebb6ad73e645b8f2d098dd3c41d2ff0da4146a02 upstream.

VMID Control 0 BIT[2:1] is VMID Divider Enable and Select

00 = VMID disabled (for OFF mode)
01 = 2 x 50kΩ divider (for normal operation)
10 = 2 x 250kΩ divider (for low power standby)
11 = 2 x 5kΩ divider (for fast start-up)

So WM8903_VMID_RES_250K should be 2 << 1, which is 4.

Signed-off-by: Axel Lin <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8737: Fixup setting VMID Impedance control register
Axel Lin [Sun, 10 May 2015 03:35:06 +0000 (11:35 +0800)]
ASoC: wm8737: Fixup setting VMID Impedance control register

commit 14ba3ec1de043260cecd9e828ea2e3a0ad302893 upstream.

According to the datasheet:
R10 (0Ah) VMID Impedance Control


DESCRIPTION: VMID impedance selection control
00: 75kΩ output
01: 300kΩ output
10: 2.5kΩ output

WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]),
so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits.

Signed-off-by: Axel Lin <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agocrypto: talitos - avoid memleak in talitos_alg_alloc()
Horia Geant? [Mon, 11 May 2015 17:03:24 +0000 (20:03 +0300)]
crypto: talitos - avoid memleak in talitos_alg_alloc()

commit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 upstream.

Fixes: 1d11911a8c57 ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function")
Signed-off-by: Horia Geanta <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
6 years agomtd: fix: avoid race condition when accessing mtd->usecount
Brian Norris [Fri, 8 May 2015 00:55:16 +0000 (17:55 -0700)]
mtd: fix: avoid race condition when accessing mtd->usecount

commit 073db4a51ee43ccb827f54a4261c0583b028d5ab upstream.

On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to
mtd->usecount were done without taking mtd_table_mutex.
kernel: Call Trace:
kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50
kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8
kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200
kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30
kernel: [<ffffffff8022006c>] __fput+0xac/0x250
kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120
kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18
        Code: 2442ffff  ac8202d8  000217fe <00020336dc820128  10400003
               00000000  0040f809  00000000
kernel: ---[ end trace 080fbb4579b47a73 ]---

Fixed by taking the mutex in blktrans_open and blktrans_release.

Note that this locking is already suggested in

struct mtd_blktrans_ops {
/* Called with mtd_table_mutex held; no race with add/remove */
int (*open)(struct mtd_blktrans_dev *dev);
void (*release)(struct mtd_blktrans_dev *dev);

But we weren't following it.

Originally reported by (and patched by) Zhang and Giuseppe,
independently. Improved and rewritten.

Reported-by: Zhang Xingcai <>
Reported-by: Giuseppe Cantavenera <>
Tested-by: Giuseppe Cantavenera <>
Acked-by: Alexander Sverdlin <>
Signed-off-by: Brian Norris <>
Signed-off-by: Ben Hutchings <>
6 years agocx24116: fix a buffer overflow when checking userspace params
Mauro Carvalho Chehab [Tue, 28 Apr 2015 21:51:17 +0000 (18:51 -0300)]
cx24116: fix a buffer overflow when checking userspace params

commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream.

The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up much more values:
drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23

Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agos5h1420: fix a buffer overflow when checking userspace params
Mauro Carvalho Chehab [Tue, 28 Apr 2015 21:34:40 +0000 (18:34 -0300)]
s5h1420: fix a buffer overflow when checking userspace params

commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream.

The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up to 7 values:
drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7

Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agohrtimer: Allow concurrent hrtimer_start() for self restarting timers
Peter Zijlstra [Tue, 20 May 2014 13:49:48 +0000 (15:49 +0200)]
hrtimer: Allow concurrent hrtimer_start() for self restarting timers

commit 5de2755c8c8b3a6b8414870e2c284914a2b42e4d upstream.

Because we drop cpu_base->lock around calling hrtimer::function, it is
possible for hrtimer_start() to come in between and enqueue the timer.

If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON
because HRTIMER_STATE_ENQUEUED will be set.

Since the above is a perfectly valid scenario, remove the BUG_ON and
make the enqueue_hrtimer() call conditional on the timer not being
enqueued already.

NOTE: in that concurrent scenario its entirely common for both sites
to want to modify the hrtimer, since hrtimers don't provide
serialization themselves be sure to provide some such that the
hrtimer::function and the hrtimer_start() caller don't both try and
fudge the expiration state at the same time.

To that effect, add a WARN when someone tries to forward an already
enqueued timer, the most common way to change the expiry of self
restarting timers. Ideally we'd put the WARN in everything modifying
the expiry but most of that is inlines and we don't need the bloat.

Fixes: 2d44ae4d7135 ("hrtimer: clean up cpu->base locking tricks")
Signed-off-by: Peter Zijlstra (Intel) <>
Cc: Ben Segall <>
Cc: Roman Gushchin <>
Cc: Paul Turner <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
6 years agoLinux 3.2.70 v3.2.70
Ben Hutchings [Thu, 6 Aug 2015 23:32:21 +0000 (00:32 +0100)]
Linux 3.2.70

6 years agoACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.
Lv Zheng [Mon, 13 Apr 2015 03:48:52 +0000 (11:48 +0800)]
ACPICA: Utilities: Cleanup to remove useless ACPI_PRINTF/FORMAT_xxx helpers.

commit 1d0a0b2f6df2bf2643fadc990eb143361eca6ada upstream.

ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of

This patch also removes above replaced macros as there are no users.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Signed-off-by: Lv Zheng <>
Signed-off-by: Bob Moore <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Dirk Behme <>
[gdavis: Move tbprint.c changes to tbutils.c due to lack of commit
 "42f4786 ACPICA: Split table print utilities to a new a
 separate file" in linux-3.10.y]
Signed-off-by: George G. Davis <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoACPICA: Utilities: Cleanup to convert physical address printing formats.
Lv Zheng [Mon, 13 Apr 2015 03:48:46 +0000 (11:48 +0800)]
ACPICA: Utilities: Cleanup to convert physical address printing formats.

commit cc2080b0e5a7c6c33ef5e9ffccbc2b8f6f861393 upstream.

ACPICA commit 7f06739db43a85083a70371c14141008f20b2198

For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
convert the %p formats.

This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.

Signed-off-by: Lv Zheng <>
Signed-off-by: Bob Moore <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Dirk Behme <>
[gdavis: Move tbinstall.c changes to tbutils.c due to lack of commit
 "42f4786 ACPICA: Split table print utilities to a new a
 separate file" in linux-3.10.y]
Signed-off-by: George G. Davis <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Drop inapplicable changes to drivers/acpi/acpica/utaddress.c and
 - Fix similar format issues in acpi_tb_add_table() and
   acpi_tb_install_table() that aren't present upstream]
Signed-off-by: Ben Hutchings <>
6 years agoACPICA: Debug output: Update output for Processor object.
Bob Moore [Fri, 17 Aug 2012 02:55:32 +0000 (10:55 +0800)]
ACPICA: Debug output: Update output for Processor object.

commit 0b232fcad225c35513c9d5719613ae552abccd82 upstream.

Cleanup output for Processor(). Length is a byte, not a word.

Signed-off-by: Bob Moore <>
Signed-off-by: Feng Tang <>
Signed-off-by: Len Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.
Lv Zheng [Mon, 13 Apr 2015 03:48:18 +0000 (11:48 +0800)]
ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.

commit 85e014b4304626972bff42249556748ad3fcf812 upstream.

commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream.

ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3

OSPMs like Linux expect an acpi_physical_address returning value from
acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
equal to sizeof (acpi_physical_address):
  drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
  In file included from include/acpi/acpi.h:64:0,
                   from include/linux/acpi.h:36,
                   from drivers/acpi/osl.c:41:
  include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
This patch corrects acpi_find_root_pointer().

Signed-off-by: Lv Zheng <>
Signed-off-by: Bob Moore <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Dirk Behme <>
Signed-off-by: George G. Davis <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agosparc32,leon: fix leon build
Sam Ravnborg [Wed, 4 Apr 2012 19:20:01 +0000 (21:20 +0200)]
sparc32,leon: fix leon build

commit d657784b70ef653350d7aa49da90a8484c29da7d upstream.

Minimal fix to allow leon to be built.

Signed-off-by: Sam Ravnborg <>
Cc: Konrad Eisele <>
Cc: Daniel Hellstrom <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agostaging: line6: avoid __sync_fetch_and_{and,or}
Arnd Bergmann [Fri, 21 Jun 2013 19:55:35 +0000 (21:55 +0200)]
staging: line6: avoid __sync_fetch_and_{and,or}

commit 9f613601482c56e05884f21565e3d218fac427ae upstream.

__sync_fetch_and_and and __sync_fetch_and_or are functions that are provided
by gcc and depending on the target architecture may be implemented in libgcc,
which is not always available in the kernel. This leads to a build failure
on ARMv5:

drivers/built-in.o: In function `line6_pcm_release':
:(.text+0x3bfe80): undefined reference to `__sync_fetch_and_and_4'
drivers/built-in.o: In function `line6_pcm_acquire':
:(.text+0x3bff30): undefined reference to `__sync_fetch_and_or_4'

To work around this, we can use the kernel-provided cmpxchg macro.

Build-tested only.

Signed-off-by: Arnd Bergmann <>
Cc: Markus Grabner <>
Acked-by: Randy Dunlap <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Fix up two more instances of __sync_fetch_and_and() that were removed
   separately upstream]
Signed-off-by: Ben Hutchings <>
6 years agoparisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds.
John David Anglin [Sat, 20 Apr 2013 19:41:06 +0000 (19:41 +0000)]
parisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds.

commit ca0ad83da17b6ba07f9eb5902e69daac90c4fa61 upstream.

The Debian experimental linux source package (3.8.5-1) build fails
with the following errors:
MODPOST 2016 modules
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/dm-verity.ko] undefined!

The attached patch resolves this problem.  It is based on the s390
implementation of ucmpdi2.c.

Signed-off-by: John David Anglin <>
Cc: "James E.J. Bottomley" <>
Signed-off-by: Helge Deller <>
Signed-off-by: Ben Hutchings <>
6 years agoUBI: fix soft lockup in ubi_check_volume()
hujianyang [Tue, 30 Dec 2014 03:56:09 +0000 (11:56 +0800)]
UBI: fix soft lockup in ubi_check_volume()

commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream.

Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.

This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.

Helped by Richard Weinberger <>

[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
[ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80:                                                       c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]

Signed-off-by: Wang Kai <>
Signed-off-by: hujianyang <>
Signed-off-by: Richard Weinberger <>
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
Ralf Baechle [Wed, 25 Mar 2015 12:21:51 +0000 (13:21 +0100)]
MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.

commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.

This is no longer needed with the fixed, new and improved definition
of cpu_has_mips_r2_exec_hazard in <asm/cpu-features.h>.

For a discussion, see

Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: Fix cpu_has_mips_r2_exec_hazard.
Ralf Baechle [Wed, 25 Mar 2015 12:14:16 +0000 (13:14 +0100)]
MIPS: Fix cpu_has_mips_r2_exec_hazard.

commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream.

Returns a non-zero value if the current processor implementation requires
an IHB instruction to deal with an instruction hazard as per MIPS R2
architecture specification, zero otherwise.

For a discussion, see

Signed-off-by: Ralf Baechle <>
[bwh: Backported to 3.2: trim the CPU type list]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: Octeon: Remove udelay() causing huge IRQ latency
Alexander Sverdlin [Wed, 18 Mar 2015 13:05:21 +0000 (14:05 +0100)]
MIPS: Octeon: Remove udelay() causing huge IRQ latency

commit 73bf3c2a500b2db8ac966469591196bf55afb409 upstream.

udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon
platforms because these operations are called from PCI_OP_READ() and
PCI_OP_WRITE() under raw_spin_lock_irqsave().

Signed-off-by: Alexander Sverdlin <>
Cc: David Daney <>
Cc: Rob Herring <>
Cc: Jiri Kosina <>
Cc: Randy Dunlap <>
Cc: Masanari Iida <>
Cc: Bjorn Helgaas <>
Cc: Mathias <>
Signed-off-by: Ralf Baechle <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: Fix race condition in lazy cache flushing.
Lars Persson [Thu, 26 Feb 2015 13:16:03 +0000 (14:16 +0100)]
MIPS: Fix race condition in lazy cache flushing.

commit 4d46a67a3eb827ccf1125959936fd51ba318dabc upstream.

The lazy cache flushing implemented in the MIPS kernel suffers from a
race condition that is exposed by do_set_pte() in mm/memory.c.

A pre-condition is a file-system that writes to the page from the CPU
in its readpage method and then calls flush_dcache_page(). One example
is ubifs. Another pre-condition is that the dcache flush is postponed
in __flush_dcache_page().

Upon a page fault for an executable mapping not existing in the
page-cache, the following will happen:
1. Write to the page
2. flush_dcache_page
3. flush_icache_page
4. set_pte_at
5. update_mmu_cache (commits the flush of a dcache-dirty page)

Between steps 4 and 5 another thread can hit the same page and it will
encounter a valid pte. Because the data still is in the L1 dcache the CPU
will fetch stale data from L2 into the icache and execute garbage.

This fix moves the commit of the cache flush to step 3 to close the
race window. It also reduces the amount of flushes on non-executable
mappings because we never enter __flush_dcache_page() for non-aliasing

Regressions can occur in drivers that mistakenly relies on the
flush_dcache_page() in get_user_pages() for DMA operations.

[ Folded in patch 9346 to fix highmem issue.]

Signed-off-by: Lars Persson <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agoFix lockup related to stop_machine being stuck in __do_softirq.
Ben Greear [Thu, 6 Jun 2013 21:29:49 +0000 (14:29 -0700)]
Fix lockup related to stop_machine being stuck in __do_softirq.

commit 34376a50fb1fa095b9d0636fa41ed2e73125f214 upstream.

The stop machine logic can lock up if all but one of the migration
threads make it through the disable-irq step and the one remaining
thread gets stuck in __do_softirq.  The reason __do_softirq can hang is
that it has a bail-out based on jiffies timeout, but in the lockup case,
jiffies itself is not incremented.

To work around this, re-add the max_restart counter in __do_irq and stop
processing irqs after 10 restarts.

Thanks to Tejun Heo and Rusty Russell and others for helping me track
this down.

This was introduced in 3.9 by commit c10d73671ad3 ("softirq: reduce

It may be worth looking into ath9k to see if it has issues with its irq
handler at a later date.

The hang stack traces look something like this:

    ------------[ cut here ]------------
    WARNING: at kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xa7()
    Watchdog detected hard LOCKUP on cpu 2
    Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc]
    Pid: 23, comm: migration/2 Tainted: G         C   3.9.4+ #11
    Call Trace:
     <NMI>   warn_slowpath_common+0x85/0x9f
    ---[ end trace 4947dfa9b0a4cec3 ]---
    BUG: soft lockup - CPU#1 stuck for 22s! [migration/1:17]
    Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 nfsv4 auth_rpcgss nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc pktgen lockd sunrpc]
    irq event stamp: 835637905
    hardirqs last  enabled at (835637904): __do_softirq+0x9f/0x257
    hardirqs last disabled at (835637905): apic_timer_interrupt+0x6d/0x80
    softirqs last  enabled at (5654720): __do_softirq+0x1ff/0x257
    softirqs last disabled at (5654725): irq_exit+0x5f/0xbb
    CPU 1
    Pid: 17, comm: migration/1 Tainted: G        WC   3.9.4+ #11 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
    RIP: tasklet_hi_action+0xf0/0xf0
    Process migration/1
    Call Trace:

Signed-off-by: Ben Greear <>
Acked-by: Tejun Heo <>
Acked-by: Pekka Riikonen <>
Cc: Eric Dumazet <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
Cc: Rui Xiang <>
6 years agosoftirq: reduce latencies
Eric Dumazet [Thu, 10 Jan 2013 23:26:34 +0000 (15:26 -0800)]
softirq: reduce latencies

commit c10d73671ad30f54692f7f69f0e09e75d3a8926a upstream.

In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.

This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.

This patch changes the fallback to ksoftirqd condition to :

- A time limit of 2 ms.
- need_resched() being set on current task

When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.

Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.

I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :

In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.

Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)

Before patch :

# netperf -H -t TCP_RR -T2,2 -- -k
to () port 0 AF_INET : first burst 0 : cpu bind

After patch :

# netperf -H -t TCP_RR -T2,2 -- -k
to () port 0 AF_INET : first burst 0 : cpu bind

Signed-off-by: Eric Dumazet <>
Cc: David Miller <>
Cc: Tom Herbert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
Cc: Rui Xiang <>
6 years agopowerpc+sparc64/mm: Remove hack in mmap randomize layout
Dan McGee [Mon, 17 Oct 2011 13:05:23 +0000 (13:05 +0000)]
powerpc+sparc64/mm: Remove hack in mmap randomize layout

commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb upstream.

Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
hold true as the value returned by get_random_int() will in fact be

different every single call. Remove the comment and simplify the code
back to its original desired form.

This reverts commit a5adc91a4b44b5d1 which is no longer necessary and
also fixes the sparc code that copied this same adjustment.

Signed-off-by: Dan McGee <>
Acked-by: David S. Miller <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
Cc: Moritz Mühlenhoff <>
6 years ago__ptrace_may_access() should not deny sub-threads
Mark Grondona [Wed, 11 Sep 2013 21:24:31 +0000 (14:24 -0700)]
__ptrace_may_access() should not deny sub-threads

commit 73af963f9f3036dffed55c3a2898598186db1045 upstream.

__ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task !=
current, this can can lead to surprising results.

For example, a sub-thread can't readlink("/proc/self/exe") if the
executable is not readable.  setup_new_exec()->would_dump() notices that
inode_permission(MAY_READ) fails and then it does
set_dumpable(suid_dumpable).  After that get_dumpable() fails.

(It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we

Change __ptrace_may_access() to use same_thread_group() instead of "task
== current".  Any security check is pointless when the tasks share the
same ->mm.

Signed-off-by: Mark Grondona <>
Signed-off-by: Ben Woodard <>
Signed-off-by: Oleg Nesterov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
Cc: Sheng Yong <>
6 years agoinclude/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid
Oleg Nesterov [Wed, 11 Sep 2013 21:20:06 +0000 (14:20 -0700)]
include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid

commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.

task_struct->pid/tgid should go away.

1. Change same_thread_group() to use task->signal for comparison.

2. Change has_group_leader_pid(task) to compare task_pid(task) with

Signed-off-by: Oleg Nesterov <>
Cc: Michal Hocko <>
Cc: Sergey Dyasly <>
Reviewed-by: "Eric W. Biederman" <>
Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Peter Zijlstra <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
Cc: Sheng Yong <>
6 years agox86/reboot: Fix a warning message triggered by stop_other_cpus()
Feng Tang [Wed, 30 May 2012 15:15:41 +0000 (23:15 +0800)]
x86/reboot: Fix a warning message triggered by stop_other_cpus()

commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 upstream.

When rebooting our 24 CPU Westmere servers with 3.4-rc6, we
always see this warning msg:

Restarting system.
machine restart
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:125
native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN
Modules linked in: igb [last unloaded: scsi_wait_scan]
Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22
Call Trace:
 <IRQ>  [<ffffffff8102a41f>] warn_slowpath_common+0x7e/0x96
 [<ffffffff8102a44c>] warn_slowpath_null+0x15/0x17
 [<ffffffff81018cf7>] native_smp_send_reschedule+0x74/0xa7
 [<ffffffff810561c1>] trigger_load_balance+0x279/0x2a6
 [<ffffffff81050112>] scheduler_tick+0xe0/0xe9
 [<ffffffff81036768>] update_process_times+0x60/0x70
 [<ffffffff81062f2f>] tick_sched_timer+0x68/0x92
 [<ffffffff81046e33>] __run_hrtimer+0xb3/0x13c
 [<ffffffff81062ec7>] ? tick_nohz_handler+0xd0/0xd0
 [<ffffffff810474f2>] hrtimer_interrupt+0xdb/0x198
 [<ffffffff81019a35>] smp_apic_timer_interrupt+0x81/0x94
 [<ffffffff81655187>] apic_timer_interrupt+0x67/0x70
 <EOI>  [<ffffffff8101a3c4>] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4
 [<ffffffff8101c680>] physflat_send_IPI_allbutself+0x12/0x14
 [<ffffffff81018db4>] native_nmi_stop_other_cpus+0x8a/0xd6
 [<ffffffff810188ba>] native_machine_shutdown+0x50/0x67
 [<ffffffff81018926>] machine_shutdown+0xa/0xc
 [<ffffffff8101897e>] native_machine_restart+0x20/0x32
 [<ffffffff810189b0>] machine_restart+0xa/0xc
 [<ffffffff8103b196>] kernel_restart+0x47/0x4c
 [<ffffffff8103b2e6>] sys_reboot+0x13e/0x17c
 [<ffffffff8164e436>] ? _raw_spin_unlock_bh+0x10/0x12
 [<ffffffff810fcac9>] ? bdi_queue_work+0xcf/0xd8
 [<ffffffff810fe82f>] ? __bdi_start_writeback+0xae/0xb7
 [<ffffffff810e0d64>] ? iterate_supers+0xa3/0xb7
 [<ffffffff816547a2>] system_call_fastpath+0x16/0x1b
---[ end trace 320af5cb1cb60c5b ]---

The root cause seems to be the
default_send_IPI_mask_allbutself_phys() takes quite some time (I
measured it could be several ms) to complete sending NMIs to all
the other 23 CPUs, and for HZ=250/1000 system, the time is long
enough for a timer interrupt to happen, which will in turn
trigger to kick load balance to a stopped CPU and cause this
warning in native_smp_send_reschedule().

So disabling the local irq before stop_other_cpu() can fix this
problem (tested 25 times reboot ok), and it is fine as there
should be nobody caring the timer interrupt in such reboot

The latest 3.4 kernel slightly changes this behavior by sending
REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR
fails, and this patch is still needed to prevent the problem.

Signed-off-by: Feng Tang <>
Acked-by: Don Zickus <>
Cc: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
Cc: Vinson Lee <>
6 years agosb_edac: Fix erroneous bytes->gigabytes conversion
Jim Snow [Tue, 18 Nov 2014 13:51:09 +0000 (14:51 +0100)]
sb_edac: Fix erroneous bytes->gigabytes conversion

commit 8c009100295597f23978c224aec5751a365bc965 upstream.

Signed-off-by: Jim Snow <>
Signed-off-by: Lukasz Anaczkowski <>
Signed-off-by: Mauro Carvalho Chehab <>
Cc: Vinson Lee <>
[lizf: Backported to 3.4:
 - adjust context
 - use debugf0() instead of edac_dbg()]
Signed-off-by: Zefan Li <>
Signed-off-by: Ben Hutchings <>
6 years agoFix sb_edac compilation with 32 bits kernels
Mauro Carvalho Chehab [Mon, 7 Nov 2011 21:26:53 +0000 (18:26 -0300)]
Fix sb_edac compilation with 32 bits kernels

commit 5b889e379f340f43b1252abde5d37a7084c846b9 upstream.

As reported by Josh Boyer <>:
> drivers/edac/sb_edac.c: In function 'get_memory_error_data':
>  drivers/edac/sb_edac.c:861:2: warning: left shift count >= width of type
>  [enabled by default]
>  <snip>
>  ERROR: "__udivdi3" [drivers/edac/sb_edac.ko] undefined!
>  make[1]: *** [__modpost] Error 1
>  make: *** [modules] Error 2

PS.: compile-tested only

Reported-by: Josh Boyer <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Prerequisite for "sb_edac: Fix erroneous bytes->gigabytes conversion"]
Signed-off-by: Ben Hutchings <>
6 years agoconfig: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
Konrad Rzeszutek Wilk [Fri, 17 Apr 2015 19:04:48 +0000 (15:04 -0400)]
config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected

commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream.

A huge amount of NIC drivers use the DMA API, however if
compiled under 32-bit an very important part of the DMA API can
be ommitted leading to the drivers not working at all
(especially if used with 'swiotlb=force iommu=soft').

As Prashant Sreedharan explains it: "the driver [tg3] uses
DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of
the dma "mapping" and dma_unmap_addr() to get the "mapping"
value. On most of the platforms this is a no-op, but ... with
"iommu=soft and swiotlb=force" this house keeping is required,
... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_
instead of the DMA address."

As such enable this even when using 32-bit kernels.

Reported-by: Ian Jackson <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Acked-by: David S. Miller <>
Acked-by: Prashant Sreedharan <>
Cc: Borislav Petkov <>
Cc: H. Peter Anvin <>
Cc: Linus Torvalds <>
Cc: Michael Chan <>
Cc: Thomas Gleixner <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: also change the def_bool (cond) to
 def_bool y + depends]
Signed-off-by: Ben Hutchings <>
6 years agonet: socket: Fix the wrong returns for recvmsg and sendmsg
Junling Zheng [Mon, 1 Jun 2015 09:28:00 +0000 (09:28 +0000)]
net: socket: Fix the wrong returns for recvmsg and sendmsg

Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream.

We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL
was expected.

We tested it through the recvmsg01 testcase come from LTP testsuit. It set
msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is
unexpected (errno 22 is expected):

recvmsg01    4  TFAIL  :  invalid socket length ; returned -1 (expected -1),
errno 14 (expected 22)

Linux mainline has no this bug for commit 08adb7dab fixes it accidentally.
However, it is too large and complex to be backported to LTS 3.10.

Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match
copy_msghdr_from_user() behaviour) made get_compat_msghdr() return
error if msg_sys->msg_namelen was negative, which changed the behaviors
of recvmsg and sendmsg syscall in a lib32 system:

Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would
return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen
was invalid and then syscall returned -EINVAL, which is correct.

And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will
fail and wants to return -EINVAL, however, the outer syscall will return
-EFAULT directly, which is unexpected.

This patch gets the return value of get_compat_msghdr() as well as
copy_msghdr_from_user(), then returns this expected value if
get_compat_msghdr() fails.

Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour)
Signed-off-by: Junling Zheng <>
Signed-off-by: Hanbing Xu <>
Cc: Li Zefan <>
Cc: Al Viro <>
Cc: David Miller <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoslub: refactoring unfreeze_partials()
Joonsoo Kim [Fri, 8 Jun 2012 17:23:16 +0000 (02:23 +0900)]
slub: refactoring unfreeze_partials()

commit 43d77867a4f333de4e4189114c480dd365133c09 upstream.

Current implementation of unfreeze_partials() is so complicated,
but benefit from it is insignificant. In addition many code in
do {} while loop have a bad influence to a fail rate of cmpxchg_double_slab.
Under current implementation which test status of cpu partial slab
and acquire list_lock in do {} while loop,
we don't need to acquire a list_lock and gain a little benefit
when front of the cpu partial slab is to be discarded, but this is a rare case.
In case that add_partial is performed and cmpxchg_double_slab is failed,
remove_partial should be called case by case.

I think that these are disadvantages of current implementation,
so I do refactoring unfreeze_partials().

Minimizing code in do {} while loop introduce a reduced fail rate
of cmpxchg_double_slab. Below is output of 'slabinfo -r kmalloc-256'
when './perf stat -r 33 hackbench 50 process 4000 > /dev/null' is done.

** before **
Cmpxchg_double Looping
Locked Cmpxchg Double redos   182685
Unlocked Cmpxchg Double redos 0

** after **
Cmpxchg_double Looping
Locked Cmpxchg Double redos   177995
Unlocked Cmpxchg Double redos 1

We can see cmpxchg_double_slab fail rate is improved slightly.

Bolow is output of './perf stat -r 30 hackbench 50 process 4000 > /dev/null'.

** before **
 Performance counter stats for './hackbench 50 process 4000' (30 runs):

     108517.190463 task-clock                #    7.926 CPUs utilized            ( +-  0.24% )
         2,919,550 context-switches          #    0.027 M/sec                    ( +-  3.07% )
           100,774 CPU-migrations            #    0.929 K/sec                    ( +-  4.72% )
           124,201 page-faults               #    0.001 M/sec                    ( +-  0.15% )
   401,500,234,387 cycles                    #    3.700 GHz                      ( +-  0.24% )
   <not supported> stalled-cycles-frontend
   <not supported> stalled-cycles-backend
   250,576,913,354 instructions              #    0.62  insns per cycle          ( +-  0.13% )
    45,934,956,860 branches                  #  423.297 M/sec                    ( +-  0.14% )
       188,219,787 branch-misses             #    0.41% of all branches          ( +-  0.56% )

      13.691837307 seconds time elapsed                                          ( +-  0.24% )

** after **
 Performance counter stats for './hackbench 50 process 4000' (30 runs):

     107784.479767 task-clock                #    7.928 CPUs utilized            ( +-  0.22% )
         2,834,781 context-switches          #    0.026 M/sec                    ( +-  2.33% )
            93,083 CPU-migrations            #    0.864 K/sec                    ( +-  3.45% )
           123,967 page-faults               #    0.001 M/sec                    ( +-  0.15% )
   398,781,421,836 cycles                    #    3.700 GHz                      ( +-  0.22% )
   <not supported> stalled-cycles-frontend
   <not supported> stalled-cycles-backend
   250,189,160,419 instructions              #    0.63  insns per cycle          ( +-  0.09% )
    45,855,370,128 branches                  #  425.436 M/sec                    ( +-  0.10% )
       169,881,248 branch-misses             #    0.37% of all branches          ( +-  0.43% )

      13.596272341 seconds time elapsed                                          ( +-  0.22% )

No regression is found, but rather we can see slightly better result.

Acked-by: Christoph Lameter <>
Signed-off-by: Joonsoo Kim <>
Signed-off-by: Pekka Enberg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
Cc: Zefan Li <>
6 years agodebugfs: Fix statfs() regression in 3.2.69
Ben Hutchings [Sat, 1 Aug 2015 18:55:11 +0000 (19:55 +0100)]
debugfs: Fix statfs() regression in 3.2.69

Commit 915f4f86ddc4 ("debugfs: leave freeing a symlink body until inode
eviction", commit 0db59e59299f upstream) changed debugfs to define its
own super_operations and implement the evict_inode operation.

Luis Henriques pointed out that it needs to define the statfs
operation, as in simple_super_operations which it was using before.

Reported-by: Luis Henriques <>
Signed-off-by: Ben Hutchings <>
6 years agosctp: Fix race between OOTB responce and route removal
Alexander Sverdlin [Mon, 29 Jun 2015 08:41:03 +0000 (10:41 +0200)]
sctp: Fix race between OOTB responce and route removal

[ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]

There is NULL pointer dereference possible during statistics update if the route
used for OOTB responce is removed at unfortunate time. If the route exists when
we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
ABORT, but in the meantime route is removed under our feet, we take "no_route"
path and try to update stats with IP_INC_STATS(sock_net(asoc->, ...).

But sctp_ootb_pkt_new() used to prepare responce packet doesn't call
sctp_transport_set_owner() and therefore there is no asoc associated with this
packet. Probably temporary asoc just for OOTB responces is overkill, so just
introduce a check like in all other places in sctp_packet_transmit(), where
"asoc" is dereferenced.

To reproduce this, one needs to
0. ensure that sctp module is loaded (otherwise ABORT is not generated)
1. remove default route on the machine
2. while true; do
     ip route del [interface-specific route]
     ip route add [interface-specific route]
3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT

On x86_64 the crash looks like this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.0.5-1-ARCH #1
Hardware name: ...
task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000
RIP: 0010:[<ffffffffa05ec9ac>]  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
RSP: 0018:ffff880127c037b8  EFLAGS: 00010296
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480
RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700
RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af
R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28
R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0
FS:  0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0
 ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400
 ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520
 0000000000000000 0000000000000001 0000000000000000 0000000000000000
Call Trace:
 [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]
 [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]
 [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]
 [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210
 [<ffffffff810e0329>] ? update_process_times+0x59/0x60
 [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0
 [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0
 [<ffffffff8101f599>] ? read_tsc+0x9/0x10
 [<ffffffff8116d4b5>] ? put_page+0x55/0x60
 [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100
 [<ffffffff81462b68>] ? skb_free_head+0x58/0x80
 [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]
 [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0
 [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]
 [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]
 [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]
 [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]
 [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]
 [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30
 [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150
 [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210
 [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90
 [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370
 [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0
 [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50
 [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60
 [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0
 [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120
 [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]
 [<ffffffff8147896a>] net_rx_action+0x21a/0x360
 [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0
 [<ffffffff8107912d>] irq_exit+0xad/0xb0
 [<ffffffff8157d158>] do_IRQ+0x58/0xf0
 [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d
 [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20
 [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]
 [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0
 [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20
 [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480
 [<ffffffff8156b365>] rest_init+0x85/0x90
 [<ffffffff818eb035>] start_kernel+0x48b/0x4ac
 [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120
 [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c
 [<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184
Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9
RIP  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
 RSP <ffff880127c037b8>
CR2: 0000000000000020
---[ end trace 5aec7fd2dc983574 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
drm_kms_helper: panic occurred, switching back to text console
---[ end Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Alexander Sverdlin <>
Acked-by: Neil Horman <>
Acked-by: Marcelo Ricardo Leitner <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: sctp alway uses init_net]
Signed-off-by: Ben Hutchings <>
6 years agoneigh: do not modify unlinked entries
Julian Anastasov [Tue, 16 Jun 2015 19:56:39 +0000 (22:56 +0300)]
neigh: do not modify unlinked entries

[ Upstream commit 2c51a97f76d20ebf1f50fef908b986cb051fdff9 ]

The lockless lookups can return entry that is unlinked.
Sometimes they get reference before last neigh_cleanup_and_release,
sometimes they do not need reference. Later, any
modification attempts may result in the following problems:

1. entry is not destroyed immediately because neigh_update
can start the timer for dead entry, eg. on change to NUD_REACHABLE
state. As result, entry lives for some time but is invisible
and out of control.

2. __neigh_event_send can run in parallel with neigh_destroy
while refcnt=0 but if timer is started and expired refcnt can
reach 0 for second time leading to second neigh_destroy and
possible crash.

Thanks to Eric Dumazet and Ying Xue for their work and analyze
on the __neigh_event_send change.

Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour")
Fixes: a263b3093641 ("ipv4: Make neigh lookups directly in output packet path.")
Fixes: 6fd6ce2056de ("ipv6: Do not depend on rt->n in ip6_finish_output2().")
Cc: Eric Dumazet <>
Cc: Ying Xue <>
Signed-off-by: Julian Anastasov <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: drop change to __neigh_set_probe_once() which
 we don't have]
Signed-off-by: Ben Hutchings <>
6 years agopacket: avoid out of bounds read in round robin fanout
Willem de Bruijn [Wed, 17 Jun 2015 19:59:34 +0000 (15:59 -0400)]
packet: avoid out of bounds read in round robin fanout

[ Upstream commit 468479e6043c84f5a65299cc07cb08a22a28c2b1 ]

PACKET_FANOUT_LB computes f->rr_cur such that it is modulo
f->num_members. It returns the old value unconditionally, but
f->num_members may have changed since the last store. Ensure
that the return value is always < num.

When modifying the logic, simplify it further by replacing the loop
with an unconditional atomic increment.

Fixes: dc99f600698d ("packet: Add fanout support.")
Suggested-by: Eric Dumazet <>
Signed-off-by: Willem de Bruijn <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust context
 - Demux functions return a sock pointer, not an index]
Signed-off-by: Ben Hutchings <>
6 years agopacket: read num_members once in packet_rcv_fanout()
Eric Dumazet [Tue, 16 Jun 2015 14:59:11 +0000 (07:59 -0700)]
packet: read num_members once in packet_rcv_fanout()

[ Upstream commit f98f4514d07871da7a113dd9e3e330743fd70ae4 ]

We need to tell compiler it must not read f->num_members multiple
times. Otherwise testing if num is not zero is flaky, and we could
attempt an invalid divide by 0 in fanout_demux_cpu()

Note bug was present in packet_rcv_fanout_hash() and
packet_rcv_fanout_lb() but final 3.1 had a simple location
after commit 95ec3eb417115fb ("packet: Add 'cpu' fanout policy.")

Fixes: dc99f600698dc ("packet: Add fanout support.")
Signed-off-by: Eric Dumazet <>
Cc: Willem de Bruijn <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agobridge: fix br_stp_set_bridge_priority race conditions
Nikolay Aleksandrov [Mon, 15 Jun 2015 17:28:51 +0000 (20:28 +0300)]
bridge: fix br_stp_set_bridge_priority race conditions

[ Upstream commit 2dab80a8b486f02222a69daca6859519e05781d9 ]

After the ->set() spinlocks were removed br_stp_set_bridge_priority
was left running without any protection when used via sysfs. It can
race with port add/del and could result in use-after-free cases and
corrupted lists. Tested by running port add/del in a loop with stp
enabled while setting priority in a loop, crashes are easily
The spinlocks around sysfs ->set() were removed in commit:
14f98f258f19 ("bridge: range check STP parameters")
There's also a race condition in the netlink priority support that is
fixed by this change, but it was introduced recently and the fixes tag
covers it, just in case it's needed the commit is:
af615762e972 ("bridge: add ageing_time, stp_state, priority over netlink")

Signed-off-by: Nikolay Aleksandrov <>
Fixes: 14f98f258f19 ("bridge: range check STP parameters")
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoxen: netback: read hotplug script once at start of day.
Ian Campbell [Mon, 1 Jun 2015 10:30:24 +0000 (11:30 +0100)]
xen: netback: read hotplug script once at start of day.

[ Upstream commit 31a418986a5852034d520a5bab546821ff1ccf3d ]

When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).

In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.

A recent change to the hypervisor exposed this race such that we now
sometimes lose it (where apparently we didn't ever before).

Instead read the hotplug script configuration during setup and use it
for the lifetime of the backend device.

The apparently more obvious fix of moving the transition to
state=Closed in netback_remove() to after the uevent does not work
because it is possible that we are already in state=Closed (in
reaction to the guest having disconnected as it shutdown). Being
already in Closed means the toolstack is at liberty to start tearing
down the xenstore directories. In principal it might be possible to
arrange to unregister the device sooner (e.g on transition to Closing)
such that xenstore would still be there but this state machine is
fragile and prone to anger...

A modern Xen system only relies on the hotplug uevent for driver
domains, when the backend is in the same domain as the toolstack it
will run the necessary setup/teardown directly in the correct sequence
wrt xenstore changes.

Signed-off-by: Ian Campbell <>
Acked-by: Wei Liu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agounix/caif: sk_socket can disappear when state is unlocked
Mark Salyzyn [Tue, 26 May 2015 15:22:19 +0000 (08:22 -0700)]
unix/caif: sk_socket can disappear when state is unlocked

[ Upstream commit b48732e4a48d80ed4a14812f0bab09560846514e ]

got a rare NULL pointer dereference in clear_bit

Signed-off-by: Mark Salyzyn <>
Acked-by: Hannes Frederic Sowa <>
v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c
v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agonet: dp83640: fix broken calibration routine.
Richard Cochran [Mon, 25 May 2015 09:55:43 +0000 (11:55 +0200)]
net: dp83640: fix broken calibration routine.

[ Upstream commit 397a253af5031de4a4612210055935309af4472c ]

Currently, the calibration function that corrects the initial offsets
among multiple devices only works the first time.  If the function is
called more than once, the calibration fails and bogus offsets will be
programmed into the devices.

In a well hidden spot, the device documentation tells that trigger indexes
0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work.

This patch fixes the issue by using one of the special triggers during the
recalibration method.

Signed-off-by: Richard Cochran <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agopowerpc: Don't skip ePAPR spin-table CPUs
Scott Wood [Wed, 25 Jun 2014 01:15:51 +0000 (20:15 -0500)]
powerpc: Don't skip ePAPR spin-table CPUs

commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream.

Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup
CPUs with bad status" broke ePAPR SMP booting.  ePAPR says that CPUs
that aren't presently running shall have status of disabled, with
enable-method being used to determine whether the CPU can be enabled.

Fix by checking for spin-table, which is currently the only supported

Signed-off-by: Scott Wood <>
Cc: Michael Neuling <>
Cc: Emil Medve <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
Cc: Jonathan Toppins <>
6 years agopowerpc: Make logical to real cpu mapping code endian safe
Anton Blanchard [Tue, 6 Aug 2013 16:01:32 +0000 (02:01 +1000)]
powerpc: Make logical to real cpu mapping code endian safe

commit ac13282dff13cd0f4da0f0ccb134bc29bfa10255 upstream.

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
[jt: fixed up context due to commit 59a53afe70fd530040bdc69581f03d880157f15a
     already being backported.]
Signed-off-by: Jonathan Toppins <>
Reviewed-by: Andy Gospodarek <>
Acked-by: Curt Brune <>
Acked-by: Roopa Prabhu <>
Signed-off-by: Ben Hutchings <>
6 years agodt: Add empty of_property_match_string() function
Thierry Reding [Fri, 13 Apr 2012 14:18:34 +0000 (16:18 +0200)]
dt: Add empty of_property_match_string() function

commit bd3d5500f0c41a30149cb184362716096a17bc75 upstream.

This commit adds an empty of_property_match_string() function for
!CONFIG_OF builds.

Acked-by: Rob Herring <>
Signed-off-by: Thierry Reding <>
Signed-off-by: Ben Hutchings <>
Cc: Jonathan Toppins <>
6 years agoof: Add of_property_match_string() to find index into a string list
Grant Likely [Mon, 12 Dec 2011 16:25:58 +0000 (09:25 -0700)]
of: Add of_property_match_string() to find index into a string list

commit 7aff0fe33033fc75b61446ba29d38b1b1354af9f upstream.

Add a helper function for finding the index of a string in a string
list property.  This helper is useful for bindings that use a separate
*-name property for attaching names to tuples in another property such
as 'reg' or 'gpios'.

Signed-off-by: Grant Likely <>
[jt: dropped changes to files not existing in the 3.2 tree]
Signed-off-by: Jonathan Toppins <>
Reviewed-by: Andy Gospodarek <>
Acked-by: Curt Brune <>
Acked-by: Roopa Prabhu <>
Signed-off-by: Ben Hutchings <>
6 years agoipvs: kernel oops - do_ip_vs_get_ctl
Hans Schillstrom [Thu, 26 Apr 2012 05:47:44 +0000 (07:47 +0200)]
ipvs: kernel oops - do_ip_vs_get_ctl

commit 8537de8a7ab6681cc72fb0411ab1ba7fdba62dd0 upstream.

Change order of init so netns init is ready
when register ioctl and netlink.

Whitespace fixes and __init added.

Reported-by: "Ryan O'Hara" <>
Signed-off-by: Hans Schillstrom <>
Acked-by: Julian Anastasov <>
Signed-off-by: Jesper Dangaard Brouer <>
Signed-off-by: Simon Horman <>
Signed-off-by: Ben Hutchings <>
Cc: Andreas Unterkircher <>
6 years agosctp: fix ASCONF list handling
Marcelo Ricardo Leitner [Fri, 12 Jun 2015 13:16:41 +0000 (10:16 -0300)]
sctp: fix ASCONF list handling

commit 2d45a02d0166caf2627fe91897c6ffc3b19514c4 upstream.

->auto_asconf_splist is per namespace and mangled by functions like
sctp_setsockopt_auto_asconf() which doesn't guarantee any serialization.

Also, the call to inet_sk_copy_descendant() was backuping
->auto_asconf_list through the copy but was not honoring
->do_auto_asconf, which could lead to list corruption if it was
different between both sockets.

This commit thus fixes the list handling by using ->addr_wq_lock
spinlock to protect the list. A special handling is done upon socket
creation and destruction for that. Error handlig on sctp_init_sock()
will never return an error after having initialized asconf, so
sctp_destroy_sock() can be called without addrq_wq_lock. The lock now
will be take on sctp_close_sock(), before locking the socket, so we
don't do it in inverse order compared to sctp_addr_wq_timeout_handler().

Instead of taking the lock on sctp_sock_migrate() for copying and
restoring the list values, it's preferred to avoid rewritting it by
implementing sctp_copy_descendant().

Issue was found with a test application that kept flipping sysctl
default_auto_asconf on and off, but one could trigger it by issuing
simultaneous setsockopt() calls on multiple sockets or by
creating/destroying sockets fast enough. This is only triggerable

Fixes: 9f7d653b67ae ("sctp: Add Auto-ASCONF support (core).")
Reported-by: Ji Jianwen <>
Suggested-by: Neil Horman <>
Suggested-by: Hannes Frederic Sowa <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: Marcelo Ricardo Leitner <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Most per-netns state is global]
Signed-off-by: Ben Hutchings <>
6 years agoudp: fix behavior of wrong checksums
Eric Dumazet [Sat, 30 May 2015 16:16:53 +0000 (09:16 -0700)]
udp: fix behavior of wrong checksums

commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream.

We have two problems in UDP stack related to bogus checksums :

1) We return -EAGAIN to application even if receive queue is not empty.
   This breaks applications using edge trigger epoll()

2) Under UDP flood, we can loop forever without yielding to other
   processes, potentially hanging the host, especially on non SMP.

This patch is an attempt to make things better.

We might in the future add extra support for rt applications
wanting to better control time spent doing a recv() in a hostile
environment. For example we could validate checksums before queuing
packets in socket receive queue.

Signed-off-by: Eric Dumazet <>
Cc: Willem de Bruijn <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agopipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
Ben Hutchings [Mon, 15 Jun 2015 02:51:55 +0000 (03:51 +0100)]
pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.


Signed-off-by: Ben Hutchings <>
6 years agotracing: Have filter check for balanced ops
Steven Rostedt [Mon, 15 Jun 2015 21:50:25 +0000 (17:50 -0400)]
tracing: Have filter check for balanced ops

commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.

When the following filter is used it causes a warning to trigger:

 # cd /sys/kernel/debug/tracing
 # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
 # cat events/ext4/ext4_truncate_exit/filter
parse_error: No error

 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
 Modules linked in: bnep lockd grace bluetooth  ...
 CPU: 3 PID: 1223 Comm: bash Tainted: G        W       4.1.0-rc3-test+ #450
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
  0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
  0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
  ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
 Call Trace:
  [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
  [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
  [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
  [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
  [<ffffffff81159065>] replace_preds+0x3c5/0x990
  [<ffffffff811596b2>] create_filter+0x82/0xb0
  [<ffffffff81159944>] apply_event_filter+0xd4/0x180
  [<ffffffff81152bbf>] event_filter_write+0x8f/0x120
  [<ffffffff811db2a8>] __vfs_write+0x28/0xe0
  [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
  [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
  [<ffffffff811dc408>] vfs_write+0xb8/0x1b0
  [<ffffffff811dc72f>] SyS_write+0x4f/0xb0
  [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
 ---[ end trace e11028bd95818dcd ]---

Worse yet, reading the error message (the filter again) it says that
there was no error, when there clearly was. The issue is that the
code that checks the input does not check for balanced ops. That is,
having an op between a closed parenthesis and the next token.

This would only cause a warning, and fail out before doing any real
harm, but it should still not caues a warning, and the error reported
should work:

 # cd /sys/kernel/debug/tracing
 # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
 # cat events/ext4/ext4_truncate_exit/filter
parse_error: Meaningless filter expression

And give no kernel warning.

Cc: Peter Zijlstra <>
Cc: Ingo Molnar <>
Cc: Arnaldo Carvalho de Melo <>
Reported-by: Vince Weaver <>
Tested-by: Vince Weaver <>
Signed-off-by: Steven Rostedt <>
[bwh: Backported to 3.2: drop the check for OP_NOT, which we don't have]
Signed-off-by: Ben Hutchings <>
6 years agoring-buffer-benchmark: Fix the wrong sched_priority of producer
Wang Long [Wed, 10 Jun 2015 08:12:37 +0000 (08:12 +0000)]
ring-buffer-benchmark: Fix the wrong sched_priority of producer

commit 108029323910c5dd1ef8fa2d10da1ce5fbce6e12 upstream.

The producer should be used producer_fifo as its sched_priority,
so correct it.

Signed-off-by: Wang Long <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
6 years agobridge: fix multicast router rlist endless loop
Nikolay Aleksandrov [Tue, 9 Jun 2015 17:23:57 +0000 (10:23 -0700)]
bridge: fix multicast router rlist endless loop

commit 1a040eaca1a22f8da8285ceda6b5e4a2cb704867 upstream.

Since the addition of sysfs multicast router support if one set
multicast_router to "2" more than once, then the port would be added to
the hlist every time and could end up linking to itself and thus causing an
endless loop for rlist walkers.
So to reproduce just do:
echo 2 > multicast_router; echo 2 > multicast_router;
in a bridge port and let some igmp traffic flow, for me it hangs up
in br_multicast_flood().
Fix this by adding a check in br_multicast_add_router() if the port is
already linked.
The reason this didn't happen before the addition of multicast_router
sysfs entries is because there's a !hlist_unhashed check that prevents

Signed-off-by: Nikolay Aleksandrov <>
Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries")
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoMIPS: Fix enabling of DEBUG_STACKOVERFLOW
James Hogan [Thu, 4 Jun 2015 12:25:27 +0000 (13:25 +0100)]

commit 5f35b9cd553fd64415b563497d05a563c988dbd6 upstream.

Commit 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") added
kernel stack overflow detection, however it only enabled it conditional
upon the preprocessor definition DEBUG_STACKOVERFLOW, which is never
actually defined. The Kconfig option is called DEBUG_STACKOVERFLOW,
which manifests to the preprocessor as CONFIG_DEBUG_STACKOVERFLOW, so
switch it to using that definition instead.

Fixes: 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection")
Signed-off-by: James Hogan <>
Cc: Ralf Baechle <>
Cc: Adam Jiang <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - add new icbody type
洪一竹 [Fri, 5 Jun 2015 05:00:24 +0000 (22:00 -0700)]
Input: elantech - add new icbody type

commit 692dd1916436164e228608803dfb6cb768d6355a upstream.

This adds new icbody type to the list recognized by Elantech PS/2 driver.

Signed-off-by: Sam Hung <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - support new ICs types for version 4
Sam hung [Thu, 8 Jan 2015 21:22:43 +0000 (13:22 -0800)]
Input: elantech - support new ICs types for version 4

commit 810aa0918b2b032684c8cad13f73d6ba37ad11c0 upstream.

This change allows the driver to recognize newer Elantech touchpads.

Signed-off-by: Yi ju Hong <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - add support for newer elantech touchpads
Jordan Rife [Wed, 23 Apr 2014 00:44:51 +0000 (17:44 -0700)]
Input: elantech - add support for newer elantech touchpads

commit ae4bedf0679d99f0a9b80a7ea9b8dd205de05d06 upstream.

Newer elantech touchpads are not recognized by the current driver, since it
fails to detect their firmware version number. This prevents more advanced
touchpad features from being usable such as two-finger scrolling. This
patch allows newer touchpads to be detected and be fully functional. Tested
on Sony Vaio SVF13N17PXB.

Signed-off-by: Jordan Rife <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - add support for newer (August 2013) devices
Matt Walker [Thu, 5 Dec 2013 20:39:02 +0000 (12:39 -0800)]
Input: elantech - add support for newer (August 2013) devices

commit 9cb80b965eaf7af1369f6e16f48a05fbaaccc021 upstream.

Added detection for newer Elantech touchpads, so that kernel doesn't
fall-back to default PS/2 driver. Supports touchpads released after
~August 2013.  Fixes bug:

Tested on an Acer Aspire S7-392-6302.

Signed-off by: Matt Walker <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - fix for newer hardware versions (v7)
Matteo Delfino [Sun, 7 Jul 2013 04:52:26 +0000 (21:52 -0700)]
Input: elantech - fix for newer hardware versions (v7)

commit 9eebed7de660c0b5ab129a9de4f89d20b60de68c upstream.

* Fix version recognition in elantech_set_properties

  The new hardware reports itself as v7 but the packets'
  structure is unaltered.

* Fix packet type recognition in elantech_packet_check_v4

  The bitmask used for v6 is too wide, only the last three bits of
  the third byte in a packet (packet[3] & 0x03) are actually used to
  distinguish between packet types.
  Starting from v7, additional information (to be interpreted) is
  stored in the remaining bits (packets[3] & 0x1c).
  In addition, the value stored in (packet[0] & 0x0c) is no longer
  a constant but contains additional information yet to be deciphered.
  This change should be backwards compatible with v6 hardware.

Additional-author: Giovanni Frigione <>
Signed-off-by: Matteo Delfino <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle
John D. Blair [Thu, 4 Jun 2015 20:18:19 +0000 (13:18 -0700)]
USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle

commit df72d588c54dad57dabb3cc8a87475d8ed66d806 upstream.

Added the USB serial device ID for the HubZ dual ZigBee
and Z-Wave radio dongle.

Signed-off-by: John D. Blair <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: fix missing input volume controls in MAYA44 USB(+)
Clemens Ladisch [Wed, 3 Jun 2015 09:36:51 +0000 (11:36 +0200)]
ALSA: usb-audio: fix missing input volume controls in MAYA44 USB(+)

commit ea114fc27dc0cb9a550b6add5426720feb66262a upstream.

The driver worked around an error in the MAYA44 USB(+)'s mixer unit
descriptor by aborting before parsing the missing field.  However,
aborting parsing too early prevented parsing of the other units
connected to this unit, so the capture mixer controls would be missing.

Fix this by moving the check for this descriptor error after the parsing
of the unit's input pins.

Reported-by: nightmixes <>
Tested-by: nightmixes <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2:
 - Adjust context
 - Logging statement was different]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: add MAYA44 USB+ mixer control names
Clemens Ladisch [Wed, 3 Jun 2015 09:36:42 +0000 (11:36 +0200)]
ALSA: usb-audio: add MAYA44 USB+ mixer control names

commit 044bddb9ca8d49edb91bc22b9940a463b0dbb97f upstream.

Add mixer control names for the ESI Maya44 USB+ (which appears to be
identical width the AudioTrak Maya44 USB).

Reported-by: nightmixes <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - fix detection of touchpads where the revision matches a known rate
Hans de Goede [Tue, 2 Jun 2015 17:40:50 +0000 (10:40 -0700)]
Input: elantech - fix detection of touchpads where the revision matches a known rate

commit 5f0ee9d17aae628b22be86966471db65be21f262 upstream.

Make the check to skip the rate check more lax, so that it applies
to all hw_version 4 models.

This fixes the touchpad not being detected properly on Asus PU551LA

Reported-and-tested-by: David Zafra Gómez <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agovfs: read file_handle only once in handle_to_path
Sasha Levin [Wed, 28 Jan 2015 20:30:43 +0000 (15:30 -0500)]
vfs: read file_handle only once in handle_to_path

commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream.

We used to read file_handle twice.  Once to get the amount of extra
bytes, and once to fetch the entire structure.

This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Signed-off-by: Sasha Levin <>
Cc: Al Viro <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agox86_64: Fix strnlen_user() to not touch memory after specified maximum
Ben Hutchings [Tue, 21 Jul 2015 14:42:59 +0000 (15:42 +0100)]
x86_64: Fix strnlen_user() to not touch memory after specified maximum

Inspired by commit f18c34e483ff ("lib: Fix strnlen_user() to not touch
memory after specified maximum") upstream.  This version of
strnlen_user(), no longer present upstream, has a similar off-by-one

Signed-off-by: Ben Hutchings <>
Cc: Jan Kara <>
6 years agotarget/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST
Andy Grover [Fri, 22 May 2015 21:07:44 +0000 (14:07 -0700)]
target/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST

commit 5a7125c64def3b21f8147eca8b54949a60963942 upstream.


We need to put() the reference to the scsi host that we got in
pscsi_configure_device(). In VIRTUAL_HOST mode it is associated with
the dev_virt, not the hba_virt.

Signed-off-by: Andy Grover <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion
Wolfram Sang [Fri, 29 May 2015 10:50:56 +0000 (19:50 +0900)]
ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion

commit 1ef9f0583514508bc93427106ceef3215e4eb1a5 upstream.

Fix this from the logs:

usb 7-1: New USB device found, idVendor=046d, idProduct=08ca
usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1

Signed-off-by: Wolfram Sang <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525
Maksim A. Boyko [Sat, 10 Aug 2013 08:20:02 +0000 (12:20 +0400)]
ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525

commit 140d37de62ffe8405282a1d6498f3b4099006384 upstream.

Add the volume control quirk for avoiding the kernel warning
for the Logitech HD Webcam C525
as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2
for the Logitech HD Webcam C310.

Reported-by: Maksim Boyko <>
Tested-by: Maksim Boyko <>
Signed-off-by: Maksim Boyko <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agod_walk() might skip too much
Al Viro [Fri, 29 May 2015 03:09:19 +0000 (23:09 -0400)]
d_walk() might skip too much

commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream.

when we find that a child has died while we'd been trying to ascend,
we should go into the first live sibling itself, rather than its sibling.

Off-by-one in question had been introduced in "deal with deadlock in
d_walk()" and the fix needs to be backported to all branches this one
has been backported to.

Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: apply to the 3 copies of this logic we
 ended up with]
Signed-off-by: Ben Hutchings <>
6 years agofs, omfs: add NULL terminator in the end up the token list
Sasha Levin [Thu, 28 May 2015 22:44:29 +0000 (15:44 -0700)]
fs, omfs: add NULL terminator in the end up the token list

commit dcbff39da3d815f08750552fdd04f96b51751129 upstream.

match_token() expects a NULL terminator at the end of the token list so
that it would know where to stop.  Not having one causes it to overrun
to invalid memory.

In practice, passing a mount option that omfs didn't recognize would
sometimes panic the system.

Signed-off-by: Sasha Levin <>
Signed-off-by: Bob Copeland <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agofs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings
Andrew Morton [Thu, 28 May 2015 22:44:24 +0000 (15:44 -0700)]
fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan <>
Cc: Michael Davidson <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agolguest: fix out-by-one error in address checking.
Rusty Russell [Wed, 27 May 2015 01:29:26 +0000 (10:59 +0930)]
lguest: fix out-by-one error in address checking.

commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream.

This bug has been there since day 1; addresses in the top guest physical
page weren't considered valid.  You could map that page (the check in
check_gpte() is correct), but if a guest tried to put a pagetable there
we'd check that address manually when walking it, and kill the guest.

Signed-off-by: Rusty Russell <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agox86: bpf_jit: fix compilation of large bpf programs
Alexei Starovoitov [Fri, 22 May 2015 22:42:55 +0000 (15:42 -0700)]
x86: bpf_jit: fix compilation of large bpf programs

commit 3f7352bf21f8fd7ba3e2fcef9488756f188e12be upstream.

x86 has variable length encoding. x86 JIT compiler is trying
to pick the shortest encoding for given bpf instruction.
While doing so the jump targets are changing, so JIT is doing
multiple passes over the program. Typical program needs 3 passes.
Some very short programs converge with 2 passes. Large programs
may need 4 or 5. But specially crafted bpf programs may hit the
pass limit and if the program converges on the last iteration
the JIT compiler will be producing an image full of 'int 3' insns.
Fix this corner case by doing final iteration over bpf program.

Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
Reported-by: Daniel Borkmann <>
Signed-off-by: Alexei Starovoitov <>
Tested-by: Daniel Borkmann <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agobridge: fix parsing of MLDv2 reports
Thadeu Lima de Souza Cascardo [Fri, 22 May 2015 15:18:59 +0000 (12:18 -0300)]
bridge: fix parsing of MLDv2 reports

commit 47cc84ce0c2fe75c99ea5963c4b5704dd78ead54 upstream.

When more than a multicast address is present in a MLDv2 report, all but
the first address is ignored, because the code breaks out of the loop if
there has not been an error adding that address.

This has caused failures when two guests connected through the bridge
tried to communicate using IPv6. Neighbor discoveries would not be
transmitted to the other guest when both used a link-local address and a
static address.

This only happens when there is a MLDv2 querier in the network.

The fix will only break out of the loop when there is a failure adding a
multicast address.

The mdb before the patch:

dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp

After the patch:

dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::fb temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp
dev ovirtmgmt port bond0.86 grp ff02::d temp
dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
dev ovirtmgmt port bond0.86 grp ff02::16 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp

Fixes: 08b202b67264 ("bridge br_multicast: IPv6 MLD support.")
Reported-by: Rik Theys <>
Signed-off-by: Thadeu Lima de Souza Cascardo <>
Tested-by: Rik Theys <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
Cc: Jonathan Toppins <>
6 years agocrypto: s390/ghash - Fix incorrect ghash icv buffer handling.
Harald Freudenberger [Thu, 21 May 2015 08:01:11 +0000 (10:01 +0200)]
crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

commit a1cae34e23b1293eccbcc8ee9b39298039c3952a upstream.

Multitheaded tests showed that the icv buffer in the current ghash
implementation is not handled correctly. A move of this working ghash
buffer value to the descriptor context fixed this. Code is tested and
verified with an multithreaded application via af_alg interface.

Signed-off-by: Harald Freudenberger <>
Signed-off-by: Gerald Schaefer <>
Reported-by: Herbert Xu <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
6 years agoUSB: serial: ftdi_sio: Add support for a Motion Tracker Development Board
Patrick Riphagen [Tue, 19 May 2015 08:03:01 +0000 (10:03 +0200)]
USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board

commit 1df5b888f54070a373a73b34488cc78c2365b7b4 upstream.

This adds support for new Xsens device, Motion Tracker Development Board,
using Xsens' own Vendor ID

Signed-off-by: Patrick Riphagen <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agoxen/events: don't bind non-percpu VIRQs with percpu chip
David Vrabel [Tue, 19 May 2015 17:40:49 +0000 (18:40 +0100)]
xen/events: don't bind non-percpu VIRQs with percpu chip

commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a upstream.

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:      87246          0  xen-percpu-virq      timer0
   44:          0          0  xen-percpu-virq      debug0
   47:          0      20995  xen-percpu-virq      timer1
   51:          0          0  xen-percpu-virq      debug1
   69:          0          0   xen-dyn-virq      xen-pcpu
   74:          0          0   xen-dyn-virq      mce
   75:         29          0   xen-dyn-virq      hvc_console

Signed-off-by: David Vrabel <>
[bwh: Backported to 3.2: adjust filename, context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agosd: Disable support for 256 byte/sector disks
Mark Hounschell [Wed, 13 May 2015 08:49:09 +0000 (10:49 +0200)]
sd: Disable support for 256 byte/sector disks

commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.

256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.

Signed-off-by: Mark Hounschell <>
Signed-off-by: Hannes Reinecke <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724
David Henningsson [Wed, 13 May 2015 11:28:54 +0000 (13:28 +0200)]
ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724

commit 6ffc0898b29a2811a6c0569c5dd9b581980110df upstream.

This patch adds support for Conexant HD Audio codecs
CX20721, CX20722, CX20723 and CX20724.

Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agojbd2: fix r_count overflows leading to buffer overflow in journal recovery
Darrick J. Wong [Thu, 14 May 2015 23:11:50 +0000 (19:11 -0400)]
jbd2: fix r_count overflows leading to buffer overflow in journal recovery

commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream.

The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond.  This could crash the kernel, so fix that.

However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.

Signed-off-by: Darrick J. Wong <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Jan Kara <>
[bwh: Backported to 3.2: journal checksumming is not supported, so only
 the first fix is needed]
Signed-off-by: Ben Hutchings <>
6 years agoext4: check for zero length extent explicitly
Eryu Guan [Thu, 14 May 2015 23:00:45 +0000 (19:00 -0400)]
ext4: check for zero length extent explicitly

commit 2f974865ffdfe7b9f46a9940836c8b167342563d upstream.

The following commit introduced a bug when checking for zero length extent

5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()

Zero length extent could pass the check if lblock is zero.

Adding the explicit check for zero length back.

Signed-off-by: Eryu Guan <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
6 years agofirmware: dmi_scan: Fix ordering of product_uuid
Jean Delvare [Thu, 14 May 2015 12:40:50 +0000 (14:40 +0200)]
firmware: dmi_scan: Fix ordering of product_uuid

commit 5c1ac56b51b9d222ab202dec1ac2f4215346129d upstream.

In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function makes a decision based on the value of global variable
dmi_ver. The problem is that this variable is set right _after_
dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
regardless of the actual version implemented.

This causes /sys/class/dmi/id/product_uuid to always use the old
ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
should use the new ordering.

This is broken since kernel v3.8 for legacy DMI implementations and
since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
implementations with the 64-bit entry point are not affected.

The first breakage does not matter much as in practice legacy DMI
implementations are always for versions older than 2.6, which is when
the UUID ordering changed. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.

Signed-off-by: Jean Delvare <>
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
Acked-by: Zhenzhong Duan <>
Cc: Ben Hutchings <>
Cc: Artem Savkov <>
Cc: Ivan Khoronzhuk <>
Cc: Matt Fleming <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agodmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()
Ben Hutchings [Tue, 30 Apr 2013 22:27:46 +0000 (15:27 -0700)]
dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()

commit 79bae42d51a5d498500c890c19ef76df41d2bf59 upstream.

Move the calls to memcpy_fromio() up into the loop in
dmi_scan_machine(), and move the signature checks back down into
dmi_decode().  We need to check at 16-byte intervals but keep a 32-byte
buffer for an SMBIOS entry, so shift the buffer after each iteration.

Merge smbios_present() into dmi_present(), so we look for an SMBIOS
signature at the beginning of the given buffer and then for a DMI
signature at an offset of 16 bytes.

[ use proper buf type in dmi_present()]
Signed-off-by: Ben Hutchings <>
Reported-by: Tim McGrath <>
Tested-by: Tim Mcgrath <>
Cc: Zhenzhong Duan <>
Signed-off-by: Artem Savkov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Prerequisite for "firmware: dmi_scan: Fix ordering of product_uuid"]

6 years agopowerpc: Align TOC to 256 bytes
Anton Blanchard [Thu, 14 May 2015 04:45:40 +0000 (14:45 +1000)]
powerpc: Align TOC to 256 bytes

commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.

Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.

If they are bad, we die a few hundred instructions into boot.

Signed-off-by: Anton Blanchard <>
Signed-off-by: Michael Ellerman <>
Signed-off-by: Ben Hutchings <>
6 years agoInput: elantech - fix semi-mt protocol for v3 HW
Benjamin Tissoires [Thu, 23 Apr 2015 16:08:43 +0000 (09:08 -0700)]
Input: elantech - fix semi-mt protocol for v3 HW

commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream.

When the v3 hardware sees more than one finger, it uses the semi-mt
protocol to report the touches. However, it currently works when
num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1
finger as if num_fingers was 1.

This confuses userspace which knows how to deal with extra fingers
when all the slots are used, but not when some are missing.


Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8994: correct BCLK DIV 348 to 384
Zidan Wang [Tue, 12 May 2015 06:58:50 +0000 (14:58 +0800)]
ASoC: wm8994: correct BCLK DIV 348 to 384

commit 17fc2e0a3db11889e942c5ab15a1fcb876638f25 upstream.

According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it
to 384.

Signed-off-by: Zidan Wang <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: wm8960: fix "RINPUT3" audio route error
Zidan Wang [Tue, 12 May 2015 06:58:36 +0000 (14:58 +0800)]
ASoC: wm8960: fix "RINPUT3" audio route error

commit 85e36a1f4a735d991ba5106781ea48e89a0b8901 upstream.

It should be "RINPUT3" instead of "LINPUT3" route to "Right Input

Signed-off-by: Zidan Wang <>
Acked-by: Charles Keepax <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
6 years agoASoC: dapm: Modify widget stream name according to prefix
Koro Chen [Mon, 11 May 2015 02:36:53 +0000 (10:36 +0800)]
ASoC: dapm: Modify widget stream name according to prefix

commit fdb6eb0a12871d5bfaf266c5a0d5259a5437a72f upstream.

When there is prefix specified, currently we will add this prefix in
widget->name, but not in widget->sname.
it causes failure at snd_soc_dapm_link_dai_widgets:

if (!w->sname || !strstr(w->sname, dai_w->name))

because dai_w->name has prefix added, but w->sname does not.
We should also add prefix for stream name

Signed-off-by: Koro Chen <>
Signed-off-by: Mark Brown <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/prefix/dapm->codec->name_prefix]
Signed-off-by: Ben Hutchings <>
6 years agoKVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages
Paolo Bonzini [Thu, 2 Apr 2015 09:04:05 +0000 (11:04 +0200)]
KVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages

commit 898761158be7682082955e3efa4ad24725305fc7 upstream.

smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages
should not be reused for different values of it.  Thus, it has to be
added to the mask in kvm_mmu_pte_write.

Reviewed-by: Xiao Guangrong <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agomac80211: move WEP tailroom size check
Janusz Dziedzic [Mon, 11 May 2015 09:31:15 +0000 (11:31 +0200)]
mac80211: move WEP tailroom size check

commit 47b4e1fc4972cc43a19121bc2608a60aef3bf216 upstream.

Remove checking tailroom when adding IV as it uses only
headroom, and move the check to the ICV generation that
actually needs the tailroom.

In other case I hit such warning and datapath don't work,
when testing:
- ath9k with hw crypt enabled
- IPv6 data (ping6)

WARNING: CPU: 3 PID: 13301 at net/mac80211/wep.c:102 ieee80211_wep_add_iv+0x129/0x190 [mac80211]()
Call Trace:
[<ffffffff817bf491>] dump_stack+0x45/0x57
[<ffffffff8107746a>] warn_slowpath_common+0x8a/0xc0
[<ffffffff8107755a>] warn_slowpath_null+0x1a/0x20
[<ffffffffc09ae109>] ieee80211_wep_add_iv+0x129/0x190 [mac80211]
[<ffffffffc09ae7ab>] ieee80211_crypto_wep_encrypt+0x6b/0xd0 [mac80211]
[<ffffffffc09d3fb1>] invoke_tx_handlers+0xc51/0xf30 [mac80211]

Signed-off-by: Janusz Dziedzic <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: s/IEEE80211_WEP/WEP/]
Signed-off-by: Ben Hutchings <>
6 years agoahci: avoton port-disable reset-quirk
Dan Williams [Fri, 8 May 2015 19:23:55 +0000 (15:23 -0400)]
ahci: avoton port-disable reset-quirk

commit dbfe8ef5599a5370abc441fcdbb382b656563eb4 upstream.

Avoton AHCI occasionally sees drive probe timeouts at driver load time.
When this happens SCR_STATUS indicates device detected, but no D2H FIS
reception.  Reset the internal link state machines by bouncing
port-enable in the PCS register when this occurs.

Signed-off-by: Dan Williams <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2:
 - Adjust context
 - Call ahci_start_engine() directly]
Signed-off-by: Ben Hutchings <>
6 years agoahci: un-staticize ahci_dev_classify
Rob Herring [Fri, 17 Aug 2012 14:51:50 +0000 (09:51 -0500)]
ahci: un-staticize ahci_dev_classify

commit bbb4ab43f82adf02c8b4d0d7e7b7e79d24204b05 upstream.

Make ahci_dev_classify available to the ahci platform driver for custom
hard reset function.

Signed-off-by: Rob Herring <>
Signed-off-by: Jeff Garzik <>
Signed-off-by: Ben Hutchings <>
6 years agousb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices
Hans de Goede [Thu, 30 Apr 2015 09:09:44 +0000 (11:09 +0200)]
usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices

commit 172115090f5e739660b97694618a2ba86457063a upstream.

Without this flag some versions of these enclosures do not work.

Reported-and-tested-by: Christian Schaller <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: gracefully handle xhci_irq dead device
Joe Lawrence [Thu, 30 Apr 2015 14:16:04 +0000 (17:16 +0300)]
xhci: gracefully handle xhci_irq dead device

commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream.

If the xHCI host controller has died (ie, device removed) or suffered
other serious fatal error (STS_FATAL), then xhci_irq should handle this
condition with IRQ_HANDLED instead of -ESHUTDOWN.

Signed-off-by: Joe Lawrence <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256
Mathias Nyman [Thu, 30 Apr 2015 14:16:03 +0000 (17:16 +0300)]
xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256

commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.

Our event ring consists of only one segment, and we risk filling
the event ring in case we get isoc transfers with short intervals
such as webcams that fill a TD every microframe (125us)

With 64 TRB segment size one usb camera could fill the event ring in 8ms.
A setup with several cameras and other devices can fill up the
event ring as it is shared between all devices.
This has occurred when uvcvideo queues 5 * 32TD URBs which then
get cancelled when the video mode changes. The cancelled URBs are returned
in the xhci interrupt context and blocks the interrupt handler from
handling the new events.

A full event ring will block xhci from scheduling traffic and affect all
devices conneted to the xhci, will see errors such as Missed Service
Intervals for isoc devices, and  and Split transaction errors for LS/FS
interrupt devices.

Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring
size, which is welcome as for most isoc transfer we had to dynamically
expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo

The default size used to be 64 TRBs per segment

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxhci: fix isoc endpoint dequeue from advancing too far on transaction error
Mathias Nyman [Thu, 30 Apr 2015 14:16:02 +0000 (17:16 +0300)]
xhci: fix isoc endpoint dequeue from advancing too far on transaction error

commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream.

Isoc TDs usually consist of one TRB, sometimes two. When all goes well we
receive only one success event for a TD, and move the dequeue pointer to
the next TD.

This fails if the TD consists of two TRBs and we get a transfer error
on the first TRB, we will then see two events for that TD.

Fix this by making sure the event we get is for the last TRB in that TD
before moving the dequeue pointer to the next TD. This will resolve some
of the uvc and dvb issues with the
"ERROR Transfer event TRB DMA ptr not part of current TD" error message

Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>