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 <>
6 years agoipvs: fix memory leak in ip_vs_ctl.c
Tommi Rantala [Thu, 7 May 2015 12:12:21 +0000 (15:12 +0300)]
ipvs: fix memory leak in ip_vs_ctl.c

commit f30bf2a5cac6c60ab366c4bc6db913597bf4d6ab upstream.

Fix memory leak introduced in commit a0840e2e165a ("IPVS: netns,
ip_vs_ctl local vars moved to ipvs struct."):

unreferenced object 0xffff88005785b800 (size 2048):
  comm "(-localed)", pid 1434, jiffies 4294755650 (age 1421.089s)
  hex dump (first 32 bytes):
    bb 89 0b 83 ff ff ff ff b0 78 f0 4e 00 88 ff ff  .........x.N....
    04 00 00 00 a4 01 00 00 00 00 00 00 00 00 00 00  ................
    [<ffffffff8262ea8e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811fba74>] __kmalloc_track_caller+0x244/0x430
    [<ffffffff811b88a0>] kmemdup+0x20/0x50
    [<ffffffff823276b7>] ip_vs_control_net_init+0x1f7/0x510
    [<ffffffff8231d630>] __ip_vs_init+0x100/0x250
    [<ffffffff822363a1>] ops_init+0x41/0x190
    [<ffffffff82236583>] setup_net+0x93/0x150
    [<ffffffff82236cc2>] copy_net_ns+0x82/0x140
    [<ffffffff810ab13d>] create_new_namespaces+0xfd/0x190
    [<ffffffff810ab49a>] unshare_nsproxy_namespaces+0x5a/0xc0
    [<ffffffff810833e3>] SyS_unshare+0x173/0x310
    [<ffffffff8265cbd7>] system_call_fastpath+0x12/0x6f
    [<ffffffffffffffff>] 0xffffffffffffffff

Fixes: a0840e2e165a ("IPVS: netns, ip_vs_ctl local vars moved to ipvs struct.")
Signed-off-by: Tommi Rantala <>
Acked-by: Julian Anastasov <>
Signed-off-by: Simon Horman <>
Signed-off-by: Ben Hutchings <>
6 years agomd/raid5: don't record new size if resize_stripes fails.
NeilBrown [Fri, 8 May 2015 08:19:34 +0000 (18:19 +1000)]
md/raid5: don't record new size if resize_stripes fails.

commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.

If any memory allocation in resize_stripes fails we will return
-ENOMEM, but in some cases we update conf->pool_size anyway.

This means that if we try again, the allocations will be assumed
to be larger than they are, and badness results.

So only update pool_size if there is no error.

This bug was introduced in 2.6.17 and the patch is suitable for

Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array")
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
6 years agoACPI / init: Fix the ordering of acpi_reserve_resources()
Rafael J. Wysocki [Thu, 7 May 2015 19:19:39 +0000 (21:19 +0200)]
ACPI / init: Fix the ordering of acpi_reserve_resources()

commit b9a5e5e18fbf223502c0b2264c15024e393da928 upstream.

Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code.  On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code

Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.

Reported-and-tested-by: George McCollister <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
6 years agoocfs2: dlm: fix race between purge and get lock resource
Junxiao Bi [Tue, 5 May 2015 23:24:02 +0000 (16:24 -0700)]
ocfs2: dlm: fix race between purge and get lock resource

commit b1432a2a35565f538586774a03bf277c27fc267d upstream.

There is a race window in dlm_get_lock_resource(), which may return a
lock resource which has been purged.  This will cause the process to
hang forever in dlmlock() as the ast msg can't be handled due to its
lock resource not existing.

    dlm_get_lock_resource {
        tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash);
        if (tmpres) {
             >>>>>>>> race window, dlm_run_purge_list() may run and purge
                              the lock resource

Signed-off-by: Junxiao Bi <>
Cc: Joseph Qi <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agonilfs2: fix sanity check of btree level in nilfs_btree_root_broken()
Ryusuke Konishi [Tue, 5 May 2015 23:24:00 +0000 (16:24 -0700)]
nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()

commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream.

The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to

Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.

This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.

Signed-off-by: Ryusuke Konishi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agonfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op
Christoph Hellwig [Tue, 28 Apr 2015 13:41:15 +0000 (15:41 +0200)]
nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op

commit ebe9cb3bb13e7b9b281969cd279ce70834f7500f upstream.

If we find a non-confirmed openowner we jump to exit the function, but do
not set an error value.  Fix this by factoring out a helper to do the
check and properly set the error from nfsd4_validate_stateid.

Signed-off-by: Christoph Hellwig <>
Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agommc: core: add missing pm event in mmc_pm_notify to fix hib restore
Grygorii Strashko [Thu, 23 Apr 2015 10:43:43 +0000 (13:43 +0300)]
mmc: core: add missing pm event in mmc_pm_notify to fix hib restore

commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.

The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <>
Signed-off-by: Ulf Hansson <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoext4: move check under lock scope to close a race.
Davide Italiano [Sun, 3 May 2015 03:21:15 +0000 (23:21 -0400)]
ext4: move check under lock scope to close a race.

commit 280227a75b56ab5d35854f3a77ef74a7ad56a203 upstream.

fallocate() checks that the file is extent-based and returns
EOPNOTSUPP in case is not. Other tasks can convert from and to
indirect and extent so it's safe to check only after grabbing
the inode mutex.

Signed-off-by: Davide Italiano <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - Adjust context
 - Add the 'out' label]
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/pseries: Correct cpu affinity for dlpar added cpus
Nathan Fontenot [Thu, 30 Apr 2015 01:42:06 +0000 (20:42 -0500)]
powerpc/pseries: Correct cpu affinity for dlpar added cpus

commit f32393c943e297b8ae180c8f83d81a156c7d0412 upstream.

The incorrect ordering of operations during cpu dlpar add results in invalid
affinity for the cpu being added. The ibm,associativity property in the
device tree is populated with all zeroes for the added cpu which results in
invalid affinity mappings and all cpus appear to belong to node 0.

This occurs because rtas configure-connector is called prior to making the
rtas set-indicator calls. Phyp does not assign affinity information
for a cpu until the rtas set-indicator calls are made to set the isolation
and allocation state.

Correct the order of operations to make the rtas set-indicator
calls (done in dlpar_acquire_drc) before calling rtas configure-connector.

Fixes: 1a8061c46c46 ("powerpc/pseries: Add kernel based CPU DLPAR handling")

Signed-off-by: Nathan Fontenot <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Keep using goto instead of directly returning]
Signed-off-by: Ben Hutchings <>
6 years agogpio: sysfs: fix memory leaks and device hotplug
Johan Hovold [Tue, 21 Apr 2015 15:42:09 +0000 (17:42 +0200)]
gpio: sysfs: fix memory leaks and device hotplug

commit 483d821108791092798f5d230686868112927044 upstream.

Unregister GPIOs requested through sysfs at chip remove to avoid leaking
the associated memory and sysfs entries.

The stale sysfs entries prevented the gpio numbers from being exported
when the gpio range was later reused (e.g. at device reconnect).

This also fixes the related module-reference leak.

Note that kernfs makes sure that any on-going sysfs operations finish
before the class devices are unregistered and that further accesses

The chip exported flag is used to prevent gpiod exports during removal.
This also makes it harder to trigger, but does not fix, the related race
between gpiochip_remove and export_store, which is really a race with
gpiod_request that needs to be addressed separately.

Also note that this would prevent the crashes (e.g. NULL-dereferences)
at reconnect that affects pre-3.18 kernels, as well as use-after-free on
operations on open attribute files on pre-3.14 kernels (prior to

Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <>
Signed-off-by: Linus Walleij <>
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Move up initialisation of 'desc' in gpio_export()
 - Use global 'gpio_desc' array and gpio_free() function in
Signed-off-by: Ben Hutchings <>
6 years agogpio: unregister gpiochip device before removing it
Johan Hovold [Mon, 12 Jan 2015 16:12:29 +0000 (17:12 +0100)]
gpio: unregister gpiochip device before removing it

commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream.

Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.

Signed-off-by: Johan Hovold <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoxen-pciback: Add name prefix to global 'permissive' variable
Ben Hutchings [Sun, 12 Apr 2015 23:26:35 +0000 (00:26 +0100)]
xen-pciback: Add name prefix to global 'permissive' variable

commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 upstream.

The variable for the 'permissive' module parameter used to be static
but was recently changed to be extern.  This puts it in the kernel
global namespace if the driver is built-in, so its name should begin
with a prefix identifying the driver.

Signed-off-by: Ben Hutchings <>
Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register")
Signed-off-by: David Vrabel <>
6 years agoUSB: pl2303: Remove support for Samsung I330
Jason A. Donenfeld [Wed, 22 Apr 2015 12:35:08 +0000 (14:35 +0200)]
USB: pl2303: Remove support for Samsung I330

commit 48ef23a4f686b1e4519d4193c20d26834ff810ff upstream.

This phone is already supported by the visor driver.

Signed-off-by: Jason A. Donenfeld <>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoUSB: cp210x: add ID for KCF Technologies PRN device
Mark Edwards [Tue, 14 Apr 2015 12:52:34 +0000 (08:52 -0400)]
USB: cp210x: add ID for KCF Technologies PRN device

commit c735ed74d83f8ecb45c4c4c95a16853c9c3c8157 upstream.

Added the USB serial console device ID for KCF Technologies PRN device
which has a USB port for its serial console.

Signed-off-by: Mark Edwards <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: emu10k1: Emu10k2 32 bit DMA mode
Peter Zubaj [Tue, 28 Apr 2015 19:57:29 +0000 (21:57 +0200)]
ALSA: emu10k1: Emu10k2 32 bit DMA mode

commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream.

Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two
modes for DMA. Second mode is useful for 64 bit os with more then 2 GB
of ram (fixes problems with big soundfont loading)

1) 32MB from 2 GB address space using 8192 pages (used now as default)
2) 16MB from 4 GB address space using 4096 pages

Mode is set using HCFG_EXPANDED_MEM flag in HCFG register.
Also format of emu10k2 page table is then different.

Signed-off-by: Peter Zubaj <>
Tested-by: Takashi Iwai <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: emux: Fix mutex deadlock in OSS emulation
Takashi Iwai [Tue, 28 Apr 2015 15:11:44 +0000 (17:11 +0200)]
ALSA: emux: Fix mutex deadlock in OSS emulation

commit 1c94e65c668f44d2c69ae7e7fc268ab3268fba3e upstream.

The OSS emulation in synth-emux helper has a potential AB/BA deadlock
at the simultaneous closing and opening:

  close ->
    snd_seq_release() ->
      sne_seq_free_client() ->
        snd_seq_delete_all_ports(): takes client->ports_mutex ->
  port_delete() ->
    snd_emux_unuse(): takes emux->register_mutex

  open ->
    snd_seq_oss_open() ->
      snd_emux_open_seq_oss(): takes emux->register_mutex ->
        snd_seq_event_port_attach() ->
  snd_seq_create_port(): takes client->ports_mutex

This patch addresses the deadlock by reducing the rance taking
emux->register_mutex in snd_emux_open_seq_oss().  The lock is needed
for the refcount handling, so move it locally.  The calls in
emux_seq.c are already with the mutex, thus they are replaced with the
version without mutex lock/unlock.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoserial: of-serial: Remove device_type = "serial" registration
Michal Simek [Tue, 14 Apr 2015 10:03:09 +0000 (12:03 +0200)]
serial: of-serial: Remove device_type = "serial" registration

commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.

Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.

When PORT_UNKNOWN is setup probe will fail anyway.

Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"

This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.

Signed-off-by: Michal Simek <>
Acked-by: Arnd Bergmann <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years agoserial: xilinx: Use platform_get_irq to get irq description structure
Michal Simek [Mon, 13 Apr 2015 14:34:21 +0000 (16:34 +0200)]
serial: xilinx: Use platform_get_irq to get irq description structure

commit 5c90c07b98c02198d9777a7c4f3047b0a94bf7ed upstream.

For systems with CONFIG_SERIAL_OF_PLATFORM=y and device_type =
"serial"; property in DT of_serial.c driver maps and unmaps IRQ (because
driver probe fails). Then a driver is called but irq mapping is not
created that's why driver is failing again in again on request_irq().
Based on this use platform_get_irq() instead of platform_get_resource()
which is doing irq_desc allocation and driver itself can request IRQ.

Fix both xilinx serial drivers in the tree.

Signed-off-by: Michal Simek <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Return directly on failure in xuartps_probe()]
Signed-off-by: Ben Hutchings <>
6 years agortlwifi: rtl8192cu: Fix kernel deadlock
Larry Finger [Fri, 24 Apr 2015 16:03:37 +0000 (11:03 -0500)]
rtlwifi: rtl8192cu: Fix kernel deadlock

commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.

The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.

This bug is reported at

Reported-by: Bernhard Wiedemann <>
Tested-by: Bernhard Wiedemann <>
Signed-off-by: Larry Finger <>
Cc: Bernhard Wiedemann <>
Cc: Takashi Iwai<>
Signed-off-by: Kalle Valo <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
6 years agocdc-acm: prevent infinite loop when parsing CDC headers.
Quentin Casasnovas [Tue, 14 Apr 2015 09:25:43 +0000 (11:25 +0200)]
cdc-acm: prevent infinite loop when parsing CDC headers.

commit 0d3bba0287d4e284c3ec7d3397e81eec920d5e7e upstream.

Phil and I found out a problem with commit:

  7e860a6e7aa6 ("cdc-acm: add sanity checks")

It added some sanity checks to ignore potential garbage in CDC headers but
also introduced a potential infinite loop.  This can happen at the first
loop iteration (elength = 0 in that case) if the description isn't a
DT_CS_INTERFACE or later if 'buffer[0]' is zero.

It should also be noted that the wrong length was being added to 'buffer'
in case 'buffer[1]' was not a DT_CS_INTERFACE descriptor, since elength was
assigned after that check in the loop.

A specially crafted USB device could be used to trigger this infinite loop.

Fixes: 7e860a6e7aa6 ("cdc-acm: add sanity checks")
Signed-off-by: Phil Turnbull <>
Signed-off-by: Quentin Casasnovas <>
CC: Sergei Shtylyov <>
CC: Oliver Neukum <>
CC: Adam Lee <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
6 years ago3w-9xxx: fix command completion race
Christoph Hellwig [Thu, 23 Apr 2015 07:48:51 +0000 (09:48 +0200)]
3w-9xxx: fix command completion race

commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream.

The 3w-9xxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

Signed-off-by: Christoph Hellwig <>
Acked-by: Adam Radford <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years ago3w-xxxx: fix command completion race
Christoph Hellwig [Thu, 23 Apr 2015 07:48:50 +0000 (09:48 +0200)]
3w-xxxx: fix command completion race

commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream.

The 3w-xxxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

Signed-off-by: Christoph Hellwig <>
Acked-by: Adam Radford <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years ago3w-sas: fix command completion race
Christoph Hellwig [Thu, 23 Apr 2015 07:48:49 +0000 (09:48 +0200)]
3w-sas: fix command completion race

commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream.

The 3w-sas driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

Signed-off-by: Christoph Hellwig <>
Reported-by: Torsten Luettgert <>
Tested-by: Bernd Kardatzki <>
Acked-by: Adam Radford <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: emux: Fix mutex deadlock at unloading
Takashi Iwai [Mon, 27 Apr 2015 12:50:39 +0000 (14:50 +0200)]
ALSA: emux: Fix mutex deadlock at unloading

commit 07b0e5d49d227e3950cb13a3e8caf248ef2a310e upstream.

The emux-synth driver has a possible AB/BA mutex deadlock at unloading
the emu10k1 driver:

  snd_emux_free() ->
    snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) ->
      snd_seq_delete_kernel_client() ->
        snd_seq_free_client(): mutex_lock(&register_mutex)

  snd_seq_release() ->
    snd_seq_free_client(): mutex_lock(&register_mutex) ->
      snd_seq_delete_all_ports() ->
        snd_emux_unuse(): mutex_lock(&emu->register_mutex)

Basically snd_emux_detach_seq() doesn't need a protection of
emu->register_mutex as it's already being unregistered.  So, we can
get rid of this for avoiding the deadlock.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoALSA: emu10k1: Fix card shortname string buffer overflow
Takashi Iwai [Mon, 27 Apr 2015 11:00:09 +0000 (13:00 +0200)]
ALSA: emu10k1: Fix card shortname string buffer overflow

commit d02260824e2cad626fb2a9d62e27006d34b6dedc upstream.

Some models provide too long string for the shortname that has 32bytes
including the terminator, and it results in a non-terminated string
exposed to the user-space.  This isn't too critical, though, as the
string is stopped at the succeeding longname string.

This patch fixes such entries by dropping "SB" prefix (it's enough to
fit within 32 bytes, so far).  Meanwhile, it also changes strcpy()
with strlcpy() to make sure that this kind of problem won't happen in
future, too.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agolibata: Ignore spurious PHY event on LPM policy change
Gabriele Mazzotta [Sat, 25 Apr 2015 17:52:37 +0000 (19:52 +0200)]
libata: Ignore spurious PHY event on LPM policy change

commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Signed-off-by: Gabriele Mazzotta <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agolibata: Add helper to determine when PHY events should be ignored
Gabriele Mazzotta [Sat, 25 Apr 2015 17:52:36 +0000 (19:52 +0200)]
libata: Add helper to determine when PHY events should be ignored

commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
6 years agowriteback: use |1 instead of +1 to protect against div by zero
Tejun Heo [Tue, 21 Apr 2015 20:49:13 +0000 (16:49 -0400)]
writeback: use |1 instead of +1 to protect against div by zero

commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream.

mm/page-writeback.c has several places where 1 is added to the divisor
to prevent division by zero exceptions; however, if the original
divisor is equivalent to -1, adding 1 leads to division by zero.

There are three places where +1 is used for this purpose - one in
pos_ratio_polynom() and two in bdi_position_ratio().  The second one
in bdi_position_ratio() actually triggered div-by-zero oops on a
machine running a 3.10 kernel.  The divisor is

  x_intercept - bdi_setpoint + 1 == span + 1

span is confirmed to be (u32)-1.  It isn't clear how it ended up that
but it could be from write bandwidth calculation underflow fixed by
c72efb658f7c ("writeback: fix possible underflow in write bandwidth

At any rate, +1 isn't a proper protection against div-by-zero.  This
patch converts all +1 protections to |1.  Note that
bdi_update_dirty_ratelimit() was already using |1 before this patch.

Signed-off-by: Tejun Heo <>
Reviewed-by: Jan Kara <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
6 years agoKVM: VMX: Preserve host CR4.MCE value while in guest mode.
Ben Serebrin [Thu, 16 Apr 2015 18:58:05 +0000 (11:58 -0700)]
KVM: VMX: Preserve host CR4.MCE value while in guest mode.

commit 085e68eeafbf76e21848ad5bafaecec88a11dd64 upstream.

The host's decision to enable machine check exceptions should remain
in force during non-root mode.  KVM was writing 0 to cr4 on VCPU reset
and passed a slightly-modified 0 to the vmcs.guest_cr4 value.

Tested: Built.
On earlier version, tested by injecting machine check
while a guest is spinning.

Before the change, if guest CR4.MCE==0, then the machine check is
escalated to Catastrophic Error (CATERR) and the machine dies.
If guest CR4.MCE==1, then the machine check causes VMEXIT and is
handled normally by host Linux. After the change, injecting a machine
check causes normal Linux machine check handling.

Signed-off-by: Ben Serebrin <>
Reviewed-by: Venkatesh Srinivas <>
Signed-off-by: Paolo Bonzini <>
[bwh: Backported to 3.2: use read_cr4() instead of cr4_read_shadow()]
Signed-off-by: Ben Hutchings <>
6 years agomemstick: mspro_block: add missing curly braces
Dan Carpenter [Thu, 16 Apr 2015 19:48:35 +0000 (12:48 -0700)]
memstick: mspro_block: add missing curly braces

commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.

Using the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate "t_len" correctly.

Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan Carpenter <>
Cc: Alex Dubov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agoptrace: fix race between ptrace_resume() and wait_task_stopped()
Oleg Nesterov [Thu, 16 Apr 2015 19:47:29 +0000 (12:47 -0700)]
ptrace: fix race between ptrace_resume() and wait_task_stopped()

commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.

ptrace_resume() is called when the tracee is still __TASK_TRACED.  We set
tracee->exit_code and then wake_up_state() changes tracee->state.  If the
tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
wrongly looks like another report from tracee.

This confuses debugger, and since wait_task_stopped() clears ->exit_code
the tracee can miss a signal.


#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <pthread.h>
#include <assert.h>

int pid;

void *waiter(void *arg)
int stat;

for (;;) {
assert(pid == wait(&stat));
if (WSTOPSIG(stat) == SIGHUP)

assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);

int main(void)
pthread_t thread;

pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);

assert(pthread_create(&thread, NULL, waiter, NULL) == 0);

for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);

return 0;

Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
should use lock_task_sighand(child).

Signed-off-by: Oleg Nesterov <>
Reported-by: Pavel Labath <>
Tested-by: Pavel Labath <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agofirmware/ihex2fw.c: restore missing default in switch statement
Nicolas Iooss [Thu, 16 Apr 2015 19:44:02 +0000 (12:44 -0700)]
firmware/ihex2fw.c: restore missing default in switch statement

commit d43698e8abb58a6ac47d16e0f47bb55f452e4fc4 upstream.

Commit 2473238eac95 ("ihex: add support for CS:IP/EIP records") removes
the "default:" statement in the switch block, making the "return
usage();" line dead code and ihex2fw silently ignoring unknown options.
Restore this statement.

This bug was found by building with HOSTCC=clang and adding
-Wunreachable-code-return to HOSTCFLAGS.

Fixes: 2473238eac95 ("ihex: add support for CS:IP/EIP records")
Signed-off-by: Nicolas Iooss <>
Cc: Mark Brown <>
Cc: David Woodhouse <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agomegaraid_sas: use raw_smp_processor_id()
Christoph Hellwig [Wed, 15 Apr 2015 16:44:37 +0000 (09:44 -0700)]
megaraid_sas: use raw_smp_processor_id()

commit 16b8528d20607925899b1df93bfd8fbab98d267c upstream.

We only want to steer the I/O completion towards a queue, but don't
actually access any per-CPU data, so the raw_ version is fine to use
and avoids the warnings when using smp_processor_id().

Signed-off-by: Christoph Hellwig <>
Reported-by: Andy Lutomirski <>
Tested-by: Andy Lutomirski <>
Acked-by: Sumit Saxena <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: drop changes to megasas_build_dcdb_fusion()]
Signed-off-by: Ben Hutchings <>
6 years agoIB/mlx4: Fix WQE LSO segment calculation
Erez Shitrit [Thu, 2 Apr 2015 10:39:05 +0000 (13:39 +0300)]
IB/mlx4: Fix WQE LSO segment calculation

commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.

The current code decreases from the mss size (which is the gso_size
from the kernel skb) the size of the packet headers.

It shouldn't do that because the mss that comes from the stack
(e.g IPoIB) includes only the tcp payload without the headers.

The result is indication to the HW that each packet that the HW sends
is smaller than what it could be, and too many packets will be sent
for big messages.

An easy way to demonstrate one more aspect of the problem is by
configuring the ipoib mtu to be less than 2*hlen (2*56) and then
run app sending big TCP messages. This will tell the HW to send packets
with giant (negative value which under unsigned arithmetics becomes
a huge positive one) length and the QP moves to SQE state.

Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support')
Reported-by: Matthew Finlay <>
Signed-off-by: Erez Shitrit <>
Signed-off-by: Or Gerlitz <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoIB/core: don't disallow registering region starting at 0x0
Yann Droneaud [Mon, 13 Apr 2015 12:56:23 +0000 (14:56 +0200)]
IB/core: don't disallow registering region starting at 0x0

commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.

In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mmap_low_allowed SELinux knobs allow userspace to map
something at address 0x0).

This patch allows back such registration: ib_umem_get()
should probably don't care of the base address provided it
can be pinned with get_user_pages().

There's two possible overflows, in (addr + size) and in
PAGE_ALIGN(addr + size), this patch keep ensuring none
of them happen while allowing to pin memory at address
0x0. Anyway, the case of size equal 0 is no more (partially)
handled as 0-length memory region are disallowed by an
earlier check.

Cc: Shachar Raindel <>
Cc: Jack Morgenstein <>
Cc: Or Gerlitz <>
Signed-off-by: Yann Droneaud <>
Reviewed-by: Sagi Grimberg <>
Reviewed-by: Haggai Eran <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agoIB/core: disallow registering 0-sized memory region
Yann Droneaud [Mon, 13 Apr 2015 12:56:22 +0000 (14:56 +0200)]
IB/core: disallow registering 0-sized memory region

commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.

If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.

This should not be allowed: it's not expected for a memory
region to have a size equal to 0.

This patch adds a check to explicitly refuse to register
a 0-sized region.

Cc: Shachar Raindel <>
Cc: Jack Morgenstein <>
Cc: Or Gerlitz <>
Signed-off-by: Yann Droneaud <>
Signed-off-by: Doug Ledford <>
Signed-off-by: Ben Hutchings <>
6 years agofs/binfmt_elf.c: fix bug in loading of PIE binaries
Michael Davidson [Tue, 14 Apr 2015 22:47:38 +0000 (15:47 -0700)]
fs/binfmt_elf.c: fix bug in loading of PIE binaries

commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.

With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down
address allocation strategy, load_elf_binary() will attempt to map a PIE
binary into an address range immediately below mm->mmap_base.

Unfortunately, load_elf_ binary() does not take account of the need to
allocate sufficient space for the entire binary which means that, while
the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent
PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are
that is supposed to be the "gap" between the stack and the binary.

Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this
means that binaries with large data segments > 128MB can end up mapping
part of their data segment over their stack resulting in corruption of the
stack (and the data segment once the binary starts to run).

Any PIE binary with a data segment > 128MB is vulnerable to this although
address randomization means that the actual gap between the stack and the
end of the binary is normally greater than 128MB.  The larger the data
segment of the binary the higher the probability of failure.

Fix this by calculating the total size of the binary in the same way as

Signed-off-by: Michael Davidson <>
Cc: Alexander Viro <>
Cc: Jiri Kosina <>
Cc: Kees Cook <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
6 years agoACPICA: Utilities: split IO address types from data type models.
Lv Zheng [Mon, 13 Apr 2015 03:48:58 +0000 (11:48 +0800)]
ACPICA: Utilities: split IO address types from data type models.

commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream.

ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451

It is reported that on a physically 64-bit addressed machine, 32-bit kernel
can trigger crashes in accessing the memory regions that are beyond the
32-bit boundary. The region field's start address should still be 32-bit
compliant, but after a calculation (adding some offsets), it may exceed the
32-bit boundary. This case is rare and buggy, but there are real BIOSes
leaked with such issues (see References below).

This patch fixes this gap by always defining IO addresses as 64-bit, and
allows OSPMs to optimize it for a real 32-bit machine to reduce the size of
the internal objects.

Internal acpi_physical_address usages in the structures that can be fixed
by this change include:
 1. struct acpi_object_region:
    acpi_physical_address address;
 2. struct acpi_address_range:
    acpi_physical_address start_address;
    acpi_physical_address end_address;
 3. struct acpi_mem_space_context;
    acpi_physical_address address;
 4. struct acpi_table_desc
    acpi_physical_address address;
See known issues 1 for other usages.

Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer
from same problem, so this patch changes it accordingly.

For iasl, it will enforce acpi_physical_address as 32-bit to generate
32-bit OSPM compatible tables on 32-bit platforms, we need to define
ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.

Known issues:
 1. Cleanup of mapped virtual address
   In struct acpi_mem_space_context, acpi_physical_address is used as a virtual
    acpi_physical_address                   mapped_physical_address;
   It is better to introduce acpi_virtual_address or use acpi_size instead.
   This patch doesn't make such a change. Because this should be done along
   with a change to acpi_os_map_memory()/acpi_os_unmap_memory().
   There should be no functional problem to leave this unchanged except
   that only this structure is enlarged unexpectedly.

Reported-and-tested-by: Paul Menzel <>
Reported-and-tested-by: Sial Nije <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Bob Moore <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agopowerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
Anton Blanchard [Mon, 13 Apr 2015 21:51:03 +0000 (07:51 +1000)]
powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH

commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream.

We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), but we forgot to do the same for 64bit backtraces.

Signed-off-by: Anton Blanchard <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
6 years agoBtrfs: fix inode eviction infinite loop after cloning into it
Filipe Manana [Mon, 30 Mar 2015 17:23:59 +0000 (18:23 +0100)]
Btrfs: fix inode eviction infinite loop after cloning into it

commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream.

If we attempt to clone a 0 length region into a file we can end up
inserting a range in the inode's extent_io tree with a start offset
that is greater then the end offset, which triggers immediately the
following warning:

[ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]()
[ 3914.620886] BTRFS: end < start 4095 4096
[ 3914.638093] Call Trace:
[ 3914.638636]  [<ffffffff81425fd9>] dump_stack+0x4c/0x65
[ 3914.639620]  [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb
[ 3914.640789]  [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs]
[ 3914.642041]  [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48
[ 3914.643236]  [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs]
[ 3914.644441]  [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs]
[ 3914.645711]  [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs]
[ 3914.646914]  [<ffffffff8142b2fb>] ? _raw_spin_unlock+0x28/0x33
[ 3914.648058]  [<ffffffffa03cbac4>] ? test_range_bit+0xcc/0xde [btrfs]
[ 3914.650105]  [<ffffffffa03cb3c3>] lock_extent+0x13/0x15 [btrfs]
[ 3914.651361]  [<ffffffffa03db39e>] lock_extent_range+0x3d/0xcd [btrfs]
[ 3914.652761]  [<ffffffffa03de1fe>] btrfs_ioctl_clone+0x278/0x388 [btrfs]
[ 3914.654128]  [<ffffffff811226dd>] ? might_fault+0x58/0xb5
[ 3914.655320]  [<ffffffffa03e0909>] btrfs_ioctl+0xb51/0x2195 [btrfs]
[ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]---

This later makes the inode eviction handler enter an infinite loop that
keeps dumping the following warning over and over:

[ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]()
[ 3915.119913] BTRFS: end < start 4095 4096
[ 3915.137394] Call Trace:
[ 3915.137913]  [<ffffffff81425fd9>] dump_stack+0x4c/0x65
[ 3915.139154]  [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb
[ 3915.140316]  [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs]
[ 3915.141505]  [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48
[ 3915.142709]  [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs]
[ 3915.143849]  [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs]
[ 3915.145120]  [<ffffffffa038c1e3>] ? btrfs_kill_super+0x17/0x23 [btrfs]
[ 3915.146352]  [<ffffffff811548f6>] ? deactivate_locked_super+0x3b/0x50
[ 3915.147565]  [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs]
[ 3915.148785]  [<ffffffff8142b7e2>] ? _raw_write_unlock+0x28/0x33
[ 3915.149931]  [<ffffffffa03bc325>] btrfs_evict_inode+0x196/0x482 [btrfs]
[ 3915.151154]  [<ffffffff81168904>] evict+0xa0/0x148
[ 3915.152094]  [<ffffffff811689e5>] dispose_list+0x39/0x43
[ 3915.153081]  [<ffffffff81169564>] evict_inodes+0xdc/0xeb
[ 3915.154062]  [<ffffffff81154418>] generic_shutdown_super+0x49/0xef
[ 3915.155193]  [<ffffffff811546d1>] kill_anon_super+0x13/0x1e
[ 3915.156274]  [<ffffffffa038c1e3>] btrfs_kill_super+0x17/0x23 [btrfs]
[ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]---

So just bail out of the clone ioctl if the length of the region to clone
is zero, without locking any extent range, in order to prevent this issue
(same behaviour as a pwrite with a 0 length for example).

This is trivial to reproduce. For example, the steps for the test I just
made for fstests:

  mkfs.btrfs -f SCRATCH_DEV

  touch $SCRATCH_MNT/foo
  touch $SCRATCH_MNT/bar

  $CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar
  umount $SCRATCH_MNT

A test case for fstests follows soon.

Signed-off-by: Filipe Manana <>
Reviewed-by: Omar Sandoval <>
Signed-off-by: Chris Mason <>
Signed-off-by: Ben Hutchings <>
6 years agos390/hibernate: fix save and restore of kernel text section
Heiko Carstens [Wed, 25 Mar 2015 09:13:33 +0000 (10:13 +0100)]
s390/hibernate: fix save and restore of kernel text section

commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.

Sebastian reported a crash caused by a jump label mismatch after resume.
This happens because we do not save the kernel text section during suspend
and therefore also do not restore it during resume, but use the kernel image
that restores the old system.

This means that after a suspend/resume cycle we lost all modifications done
to the kernel text section.
The reason for this is the pfn_is_nosave() function, which incorrectly
returns that read-only pages don't need to be saved. This is incorrect since
we mark the kernel text section read-only.
We still need to make sure to not save and restore pages contained within
NSS and DCSS segment.
To fix this add an extra case for the kernel text section and only save
those pages if they are not contained within an NSS segment.

Fixes the following crash (and the above bugs as well):

Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0
Found:    c0 04 00 00 00 00
Expected: c0 f4 00 00 00 11
New:      c0 04 00 00 00 00
Kernel panic - not syncing: Corrupted kernel text
CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4
Call Trace:
  [<0000000000113972>] show_stack+0x72/0xf0
  [<000000000081f15e>] dump_stack+0x6e/0x90
  [<000000000081c4e8>] panic+0x108/0x2b0
  [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108
  [<0000000000112176>] __jump_label_transform+0x9e/0xd0
  [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50
  [<00000000001d1136>] multi_cpu_stop+0x12e/0x170
  [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168
  [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0
  [<0000000000158baa>] kthread+0x10a/0x110
  [<0000000000824a86>] kernel_thread_starter+0x6/0xc

Reported-and-tested-by: Sebastian Ott <>
Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: add necessary #include directives]
Signed-off-by: Ben Hutchings <>
6 years agoselinux/nlmsg: add XFRM_MSG_MAPPING
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:28 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_MAPPING

commit bd2cba07381a6dba60bc1c87ed8b37931d244da1 upstream.

This command is missing.

Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink")
CC: Martin Willi <>
Reported-by: Stephen Smalley <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoselinux/nlmsg: add XFRM_MSG_MIGRATE
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:27 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_MIGRATE

commit 8d465bb777179c4bea731b828ec484088cc9fbc1 upstream.

This command is missing.

Fixes: 5c79de6e79cd ("[XFRM]: User interface for handling XFRM_MSG_MIGRATE")
Reported-by: Stephen Smalley <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agoselinux/nlmsg: add XFRM_MSG_REPORT
Nicolas Dichtel [Fri, 10 Apr 2015 14:24:26 +0000 (16:24 +0200)]
selinux/nlmsg: add XFRM_MSG_REPORT

commit b0b59b0056acd6f157a04cc895f7e24692fb08aa upstream.

This command is missing.

Fixes: 97a64b4577ae ("[XFRM]: Introduce XFRM_MSG_REPORT.")
Reported-by: Stephen Smalley <>
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
6 years agosg_start_req(): make sure that there's not too many elements in iovec
Al Viro [Sun, 22 Mar 2015 00:08:18 +0000 (20:08 -0400)]
sg_start_req(): make sure that there's not too many elements in iovec

commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.

unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there.  If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.

X-Coverup: TINC (and there's no lumber cartel either)
Signed-off-by: Al Viro <>
[bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
 fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
 that function.]
Signed-off-by: Ben Hutchings <>
6 years agopowerpc: Fix missing L2 cache size in /sys/devices/system/cpu
Dave Olson [Fri, 3 Apr 2015 04:28:45 +0000 (21:28 -0700)]
powerpc: Fix missing L2 cache size in /sys/devices/system/cpu

commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.

This problem appears to have been introduced in 2.6.29 by commit
93197a36a9c1 "Rewrite sysfs processor cache info code".

This caused lscpu to error out on at least e500v2 devices, eg:

  error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory

Some embedded powerpc systems use cache-size in DTS for the unified L2
cache size, not d-cache-size, so we need to allow for both DTS names.
Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle

Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code")
Signed-off-by: Dave Olson <>
Signed-off-by: Michael Ellerman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Preserve __cpuinit attribute on cache_do_one_devnode_unified()]
Signed-off-by: Ben Hutchings <>
6 years agoALSA: emu10k1: don't deadlock in proc-functions
Michael Gernoth [Thu, 9 Apr 2015 21:42:15 +0000 (23:42 +0200)]
ALSA: emu10k1: don't deadlock in proc-functions

commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream.

The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read
acquire the emu_lock before accessing the FPGA. The function used
to access the FPGA (snd_emu1010_fpga_read) also tries to take
the emu_lock which causes a deadlock.
Remove the outer locking in the proc-functions (guarding only the
already safe fpga read) to prevent this deadlock.

[removed superfluous flags variables too -- tiwai]

Signed-off-by: Michael Gernoth <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
6 years agoscsi: storvsc: Fix a bug in copy_from_bounce_buffer()
K. Y. Srinivasan [Fri, 27 Mar 2015 07:27:18 +0000 (00:27 -0700)]
scsi: storvsc: Fix a bug in copy_from_bounce_buffer()

commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream.

We may exit this function without properly freeing up the maapings
we may have acquired. Fix the bug.

Signed-off-by: K. Y. Srinivasan <>
Reviewed-by: Long Li <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Keep using kmap_atomic()/kunmap_atomic(), not the sg_-prefixed functions]
Signed-off-by: Ben Hutchings <>
6 years agox86/iommu: Fix header comments regarding standard and _FINISH macros
Aravind Gopalakrishnan [Thu, 9 Apr 2015 08:51:48 +0000 (10:51 +0200)]
x86/iommu: Fix header comments regarding standard and _FINISH macros

commit b44915927ca88084a7292e4ddd4cf91036f365e1 upstream.

The comment line regarding IOMMU_INIT and IOMMU_INIT_FINISH
macros is incorrect:

  "The standard vs the _FINISH differs in that the _FINISH variant
  will continue detecting other IOMMUs in the call list..."

It should be "..the *standard* variant will continue

Fix that. Also, make it readable while at it.

Signed-off-by: Aravind Gopalakrishnan <>
Signed-off-by: Borislav Petkov <>
Cc: H. Peter Anvin <>
Cc: Thomas Gleixner <>
Fixes: 6e9636693373 ("x86, iommu: Update header comments with appropriate naming")
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
6 years agoselinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO
Nicolas Dichtel [Wed, 8 Apr 2015 16:36:42 +0000 (18:36 +0200)]
selinux/nlmsg: add XFRM_MSG_[NEW|GET]SADINFO

commit 5b5800fad072133e4a9c2efbf735baaac83dec86 upstream.

These commands are missing.

Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.")
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
6 years agoselinux/nlmsg: add XFRM_MSG_GETSPDINFO
Nicolas Dichtel [Wed, 8 Apr 2015 16:36:41 +0000 (18:36 +0200)]
selinux/nlmsg: add XFRM_MSG_GETSPDINFO

commit 5e6deebafb45fb271ae6939d48832e920b8fb74e upstream.

This command is missing.

Fixes: ecfd6b183780 ("[XFRM]: Export SPD info")
Signed-off-by: Nicolas Dichtel <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>