7 years agonet: unix: non blocking recvmsg() should not return -EINTR
Eric Dumazet [Wed, 26 Mar 2014 01:42:27 +0000 (18:42 -0700)]
net: unix: non blocking recvmsg() should not return -EINTR

[ Upstream commit de1443916791d75fdd26becb116898277bb0273f ]

Some applications didn't expect recvmsg() on a non blocking socket
could return -EINTR. This possibility was added as a side effect
of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
unix recv routines").

To hit this bug, you need to be a bit unlucky, as the u->readlock
mutex is usually held for very small periods.

Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines")
Signed-off-by: Eric Dumazet <>
Cc: Rainer Weikusat <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agobridge: multicast: add sanity check for query source addresses
Linus Lüssing [Tue, 4 Mar 2014 02:57:35 +0000 (03:57 +0100)]
bridge: multicast: add sanity check for query source addresses

[ Upstream commit 6565b9eeef194afbb3beec80d6dd2447f4091f8c ]

MLD queries are supposed to have an IPv6 link-local source address
according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
adds a sanity check to ignore such broken MLD queries.

Without this check, such malformed MLD queries can result in a
denial of service: The queries are ignored by any MLD listener
therefore they will not respond with an MLD report. However,
without this patch these malformed MLD queries would enable the
snooping part in the bridge code, potentially shutting down the
according ports towards these hosts for multicast traffic as the
bridge did not learn about these listeners.

Reported-by: Jan Stancek <>
Signed-off-by: Linus Lüssing <>
Reviewed-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk
Daniel Borkmann [Tue, 4 Mar 2014 15:35:51 +0000 (16:35 +0100)]
net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk

[ Upstream commit c485658bae87faccd7aed540fd2ca3ab37992310 ]

While working on ec0223ec48a9 ("net: sctp: fix sctp_sf_do_5_1D_ce to
verify if we/peer is AUTH capable"), we noticed that there's a skb
memory leakage in the error path.

Running the same reproducer as in ec0223ec48a9 and by unconditionally
jumping to the error label (to simulate an error condition) in
sctp_sf_do_5_1D_ce() receive path lets kmemleak detector bark about
the unfreed chunk->auth_chunk skb clone:

Unreferenced object 0xffff8800b8f3a000 (size 256):
  comm "softirq", pid 0, jiffies 4294769856 (age 110.757s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    89 ab 75 5e d4 01 58 13 00 00 00 00 00 00 00 00  ..u^..X.........
    [<ffffffff816660be>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff8119f328>] kmem_cache_alloc+0xc8/0x210
    [<ffffffff81566929>] skb_clone+0x49/0xb0
    [<ffffffffa0467459>] sctp_endpoint_bh_rcv+0x1d9/0x230 [sctp]
    [<ffffffffa046fdbc>] sctp_inq_push+0x4c/0x70 [sctp]
    [<ffffffffa047e8de>] sctp_rcv+0x82e/0x9a0 [sctp]
    [<ffffffff815abd38>] ip_local_deliver_finish+0xa8/0x210
    [<ffffffff815a64af>] nf_reinject+0xbf/0x180
    [<ffffffffa04b4762>] nfqnl_recv_verdict+0x1d2/0x2b0 [nfnetlink_queue]
    [<ffffffffa04aa40b>] nfnetlink_rcv_msg+0x14b/0x250 [nfnetlink]
    [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
    [<ffffffffa04aa7cf>] nfnetlink_rcv+0x23f/0x408 [nfnetlink]
    [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
    [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
    [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
    [<ffffffff8155d449>] ___sys_sendmsg+0x369/0x380

What happens is that commit bbd0d59809f9 clones the skb containing
the AUTH chunk in sctp_endpoint_bh_rcv() when having the edge case
that an endpoint requires COOKIE-ECHO chunks to be authenticated:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  ------------------ AUTH; COOKIE-ECHO ---------------->
  <-------------------- COOKIE-ACK ---------------------

When we enter sctp_sf_do_5_1D_ce() and before we actually get to
the point where we process (and subsequently free) a non-NULL
chunk->auth_chunk, we could hit the "goto nomem_init" path from
an error condition and thus leave the cloned skb around w/o
freeing it.

The fix is to centrally free such clones in sctp_chunk_destroy()
handler that is invoked from sctp_chunk_free() after all refs have
dropped; and also move both kfree_skb(chunk->auth_chunk) there,
so that chunk->auth_chunk is either NULL (since sctp_chunkify()
allocs new chunks through kmem_cache_zalloc()) or non-NULL with
a valid skb pointer. chunk->skb and chunk->auth_chunk are the
only skbs in the sctp_chunk structure that need to be handeled.

While at it, we should use consume_skb() for both. It is the same
as dev_kfree_skb() but more appropriately named as we are not
a device but a protocol. Also, this effectively replaces the
kfree_skb() from both invocations into consume_skb(). Functions
are the same only that kfree_skb() assumes that the frame was
being dropped after a failure (e.g. for tools like drop monitor),
usage of consume_skb() seems more appropriate in function
sctp_chunk_destroy() though.

Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
Signed-off-by: Daniel Borkmann <>
Cc: Vlad Yasevich <>
Cc: Neil Horman <>
Acked-by: Vlad Yasevich <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.57 v3.2.57
Ben Hutchings [Wed, 9 Apr 2014 01:20:47 +0000 (02:20 +0100)]
Linux 3.2.57

7 years agos390: fix kernel crash due to linkage stack instructions
Martin Schwidefsky [Mon, 3 Feb 2014 16:37:15 +0000 (17:37 +0100)]
s390: fix kernel crash due to linkage stack instructions

commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream.

The kernel currently crashes with a low-address-protection exception
if a user space process executes an instruction that tries to use the
linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
of the dispatchable-unit-control-table to point to a dummy ASTE.
Set up control register 15 to point to an empty linkage stack with no
room left.

A user space process with a linkage stack instruction will still crash
but with a different exception which is correctly translated to a
segmentation fault instead of a kernel oops.

Signed-off-by: Martin Schwidefsky <>
Signed-off-by: Ben Hutchings <>
7 years agocifs: ensure that uncached writes handle unmapped areas correctly
Jeff Layton [Fri, 14 Feb 2014 12:20:35 +0000 (07:20 -0500)]
cifs: ensure that uncached writes handle unmapped areas correctly

commit 5d81de8e8667da7135d3a32a964087c0faf5483f upstream.

It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069

cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.

Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.

[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
       v2.6.38 may have a similar problem and may need similar fix]

Reviewed-by: Pavel Shilovsky <>
Reported-by: Al Viro <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/nr_pages/npages/
 - s/wdata->pages/pages/
 - In case of an error with no data copied, we must kunmap() page 0,
   but in neither case should we free anything else]
 Thanks to Raphael Geissert for an independent backport that showed some
 bugs in my first version.]
Signed-off-by: Ben Hutchings <>
7 years agoKVM: VMX: fix use after free of vmx->loaded_vmcs
Marcelo Tosatti [Fri, 3 Jan 2014 19:00:51 +0000 (17:00 -0200)]
KVM: VMX: fix use after free of vmx->loaded_vmcs

commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.

After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate

Switch the order to avoid the problem.

Reviewed-by: Jan Kiszka <>
Signed-off-by: Marcelo Tosatti <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: MMU: handle invalid root_hpa at __direct_map
Marcelo Tosatti [Thu, 19 Dec 2013 17:28:51 +0000 (15:28 -0200)]
KVM: MMU: handle invalid root_hpa at __direct_map

commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.

It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:

1) try_async_pf -> can_do_async_pf
    -> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit

Then to load_vmcs12_host_state and kvm_mmu_reset_context.

Check for this possibility, let fault exception be regenerated.


Signed-off-by: Marcelo Tosatti <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agonet: asix: add missing flag to struct driver_info
Emil Goode [Thu, 13 Feb 2014 18:30:39 +0000 (19:30 +0100)]
net: asix: add missing flag to struct driver_info

commit d43ff4cd798911736fb39025ec8004284b1b0bc2 upstream.

The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.

Signed-off-by: Emil Goode <>
Reported-by: Bjørn Mork <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: asix: handle packets crossing URB boundaries
Emil Goode [Mon, 31 Mar 2014 15:41:32 +0000 (17:41 +0200)]
net: asix: handle packets crossing URB boundaries

commit 8b5b6f5413e97c3e8bafcdd67553d508f4f698cd upstream.

ASIX AX88772B started to pack data even more tightly. Packets and the ASIX packet
header may now cross URB boundaries. To handle this we have to introduce
some state between individual calls to asix_rx_fixup().

Signed-off-by: Lucas Stach <>
Signed-off-by: David S. Miller <>
[ Emil: backported to 3.2:
 - dropped changes to drivers/net/usb/ax88172a.c
 - Introduced some static function declarations as the functions
   are not used outside of asix.c (sparse is complaining about it) ]
Signed-off-by: Emil Goode <>
Signed-off-by: Ben Hutchings <>
7 years agoasix: asix_rx_fixup surgery to reduce skb truesizes
Eric Dumazet [Wed, 14 Mar 2012 20:18:32 +0000 (20:18 +0000)]
asix: asix_rx_fixup surgery to reduce skb truesizes

commit a9e0aca4b37885b5599e52211f098bd7f565e749 upstream.

asix_rx_fixup() is complex, and does some unnecessary memory copies (at
least on x86 where NET_IP_ALIGN is 0)

Also, it tends to provide skbs with a big truesize (4096+256 with
MTU=1500) to upper stack, so incoming trafic consume a lot of memory and
I noticed early packet drops because we hit socket rcvbuf too fast.

Switch to a different strategy, using copybreak so that we provide nice
skbs to upper stack (including the NET_SKB_PAD to avoid future head
reallocations in some paths)

With this patch, I no longer see packets drops or tcp collapses on
various tcp workload with a AX88772 adapter.

Signed-off-by: Eric Dumazet <>
Cc: Aurelien Jacobs <>
Cc: Greg Kroah-Hartman <>
Cc: Trond Wuellner <>
Cc: Grant Grundler <>
Cc: Paul Stewart <>
Reviewed-by: Grant Grundler <>
Reviewed-by: Grant Grundler <>
Signed-off-by: David S. Miller <>
[ Emil: Backported to 3.2: fixed small conflict ]
Signed-off-by: Emil Goode <>
Signed-off-by: Ben Hutchings <>
7 years agodeb-pkg: Fix cross-building linux-headers package
Ben Hutchings [Thu, 5 Dec 2013 14:37:35 +0000 (14:37 +0000)]
deb-pkg: Fix cross-building linux-headers package

commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.

builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture.  This
breaks cross-building configurations.  We should use $debarch for this

Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the

Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh." <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: Michal Marek <>
7 years agodeb-pkg: Fix building for MIPS big-endian or ARM OABI
Ben Hutchings [Thu, 5 Dec 2013 14:39:11 +0000 (14:39 +0000)]
deb-pkg: Fix building for MIPS big-endian or ARM OABI

commit c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream.

These commands will mysteriously fail:

$ make ARCH=arm versatile_defconfig
$ make ARCH=arm deb-pkg
make[1]: *** [deb-pkg] Error 1
make: *** [deb-pkg] Error 2

The Debian architecture selection for these kernel architectures does
'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this
aborts the script if grep does not find the given config symbol.

Fixes: 10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE')
Signed-off-by: Ben Hutchings <>
Signed-off-by: Michal Marek <>
7 years agodeb-pkg: use KCONFIG_CONFIG instead of .config file directly
Anisse Astier [Wed, 3 Jul 2013 14:02:03 +0000 (16:02 +0200)]
deb-pkg: use KCONFIG_CONFIG instead of .config file directly

commit d20917670ee1fd4b090555e551faea04b014ca97 upstream.

Signed-off-by: Anisse Astier <>
Reviewed-by: Ben Hutchings <>
Signed-off-by: Michal Marek <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agonet: ip, ipv6: handle gso skbs in forwarding path
Florian Westphal [Sat, 22 Feb 2014 09:33:26 +0000 (10:33 +0100)]
net: ip, ipv6: handle gso skbs in forwarding path

commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.

[ use zero netdev_feature mask to avoid backport of
  netif_skb_dev_features function ]

Marcelo Ricardo Leitner reported problems when the forwarding link path
has a lower mtu than the incoming one if the inbound interface supports GRO.

Host <mtu1500> R1 <mtu1200> R2

Host sends tcp stream which is routed via R1 and R2.  R1 performs GRO.

In this case, the kernel will fail to send ICMP fragmentation needed
messages (or pkt too big for ipv6), as GSO packets currently bypass dstmtu
checks in forward path. Instead, Linux tries to send out packets exceeding
the mtu.

When locking route MTU on Host (i.e., no ipv4 DF bit set), R1 does
not fragment the packets when forwarding, and again tries to send out
packets exceeding R1-R2 link mtu.

This alters the forwarding dstmtu checks to take the individual gso
segment lengths into account.

For ipv6, we send out pkt too big error for gso if the individual
segments are too big.

For ipv4, we either send icmp fragmentation needed, or, if the DF bit
is not set, perform software segmentation and let the output path
create fragments when the packet is leaving the machine.
It is not 100% correct as the error message will contain the headers of
the GRO skb instead of the original/segmented one, but it seems to
work fine in my (limited) tests.

Eric Dumazet suggested to simply shrink mss via ->gso_size to avoid
sofware segmentation.

However it turns out that skb_segment() assumes skb nr_frags is related
to mss size so we would BUG there.  I don't want to mess with it considering
Herbert and Eric disagree on what the correct behavior should be.

Hannes Frederic Sowa notes that when we would shrink gso_size
skb_segment would then also need to deal with the case where
SKB_MAX_FRAGS would be exceeded.

This uses sofware segmentation in the forward path when we hit ipv4
non-DF packets and the outgoing link mtu is too small.  Its not perfect,
but given the lack of bug reports wrt. GRO fwd being broken this is a
rare case anyway.  Also its not like this could not be improved later
once the dust settles.

Acked-by: Herbert Xu <>
Reported-by: Marcelo Ricardo Leitner <>
Signed-off-by: Florian Westphal <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: add and use skb_gso_transport_seglen()
Florian Westphal [Sat, 22 Feb 2014 09:33:25 +0000 (10:33 +0100)]
net: add and use skb_gso_transport_seglen()

commit de960aa9ab4decc3304959f69533eef64d05d8e8 upstream.

[ no skb_gso_seglen helper in 3.4, leave tbf alone ]

This moves part of Eric Dumazets skb_gso_seglen helper from tbf sched to
skbuff core so it may be reused by upcoming ip forwarding path patch.

Signed-off-by: Florian Westphal <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoipc/msg: fix race around refcount
Konstantin Khlebnikov [Wed, 26 Mar 2014 10:12:19 +0000 (14:12 +0400)]
ipc/msg: fix race around refcount

In older kernels (before v3.10) ipc_rcu_hdr->refcount was non-atomic int.
There was possuble double-free bug: do_msgsnd() calls ipc_rcu_putref() under
msq->q_perm->lock and RCU, while freequeue() calls it while it holds only
'rw_mutex', so there is no sinchronization between them. Two function
decrements '2' non-atomically, they both can get '0' as result.

do_msgsnd() freequeue()

msq = msg_lock_check(ns, msqid);
(caller locks spinlock)
expunge_all(msq, -EIDRM);
ss_wakeup(&msq->q_senders, 1);
msg_rmid(ns, msq);
ipc_rcu_putref(msq); ipc_rcu_putref(msq);
< both may get get --(...)->refcount == 0 >

This patch locks ipc_lock and RCU around ipc_rcu_putref in freequeue.
( RCU protects memory for spin_unlock() )

Similar bugs might be in other users of ipc_rcu_putref().

In the mainline this has been fixed in v3.10 indirectly in commmit
("ipc,sem: fine grained locking for semtimedop") by Rik van Riel.
That commit optimized locking and converted refcount into atomic.

I'm not sure that anybody should care about this bug: it's very-very unlikely
and no longer exists in actual mainline. I've found this just by looking into
the code, probably this never happens in real life.

Signed-off-by: Konstantin Khlebnikov <>
Signed-off-by: Ben Hutchings <>
7 years agonetfilter: nf_conntrack_dccp: fix skb_header_pointer API usages
Daniel Borkmann [Sun, 5 Jan 2014 23:57:54 +0000 (00:57 +0100)]
netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages

commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.

Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...

  struct dccp_hdr _dh, *dh;
  skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);

... where dh itself is a pointer that is being passed as the copy
buffer. Instead, we need to use &_dh as the forth argument so that
we're copying the data into an actual buffer that sits on the stack.

Currently, we probably could overwrite memory on the stack (e.g.
with a possibly mal-formed DCCP packet), but unintentionally, as
we only want the buffer to be placed into _dh variable.

Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
Signed-off-by: Daniel Borkmann <>
Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: Ben Hutchings <>
7 years agoext4: atomically set inode->i_flags in ext4_set_inode_flags()
Theodore Ts'o [Sun, 30 Mar 2014 14:20:01 +0000 (10:20 -0400)]
ext4: atomically set inode->i_flags in ext4_set_inode_flags()

commit 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 upstream.

Use cmpxchg() to atomically set i_flags instead of clearing out the
S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the
EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race
where an immutable file has the immutable flag cleared for a brief
window of time.

Reported-by: John Sullivan <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agostaging: speakup: Prefix set_mask_bits() symbol
Ben Hutchings [Sun, 6 Apr 2014 12:19:52 +0000 (13:19 +0100)]
staging: speakup: Prefix set_mask_bits() symbol

This is part of commit ca2beaf84d96 ('staging: speakup: Prefix
externally-visible symbols') upstream.  It is required as preparation
for commit 00a1a053ebe5 ('ext4: atomically set inode->i_flags in

Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - add manual min/max quirk for ThinkPad X240
Hans de Goede [Fri, 28 Mar 2014 08:01:38 +0000 (01:01 -0700)]
Input: synaptics - add manual min/max quirk for ThinkPad X240

commit 8a0435d958fb36d93b8df610124a0e91e5675c82 upstream.

This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.

Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - add manual min/max quirk
Benjamin Tissoires [Fri, 28 Mar 2014 07:43:00 +0000 (00:43 -0700)]
Input: synaptics - add manual min/max quirk

commit 421e08c41fda1f0c2ff6af81a67b491389b653a5 upstream.

The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.

Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.

We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).

So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.

Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.56 v3.2.56
Ben Hutchings [Tue, 1 Apr 2014 23:59:03 +0000 (00:59 +0100)]
Linux 3.2.56

7 years agoPCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
Bjorn Helgaas [Tue, 11 Mar 2014 20:22:19 +0000 (14:22 -0600)]
PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream.

Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been

Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
Reported-and-tested-by: Andreas Noever <>
Signed-off-by: Bjorn Helgaas <>
CC: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
7 years agointel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.
Konrad Rzeszutek Wilk [Thu, 16 Aug 2012 20:06:55 +0000 (22:06 +0200)]
intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.

commit 3735d524da64b70b41c764359da36f88aded3610 upstream.

If the machine is booted without any cpu_idle driver set
(b/c disable_cpuidle() has been called) we should follow
other users of cpu_idle API and check the return value
for NULL before using it.

Reported-and-tested-by: Mark van Dijk <>
Suggested-by: Jan Beulich <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agonet: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable
Daniel Borkmann [Mon, 3 Mar 2014 16:23:04 +0000 (17:23 +0100)]
net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable

[ Upstream commit ec0223ec48a90cb605244b45f7c62de856403729 ]

RFC4895 introduced AUTH chunks for SCTP; during the SCTP
handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
being optional though):

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  -------------------- COOKIE-ECHO -------------------->
  <-------------------- COOKIE-ACK ---------------------

A special case is when an endpoint requires COOKIE-ECHO
chunks to be authenticated:

  ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
  <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
  ------------------ AUTH; COOKIE-ECHO ---------------->
  <-------------------- COOKIE-ACK ---------------------

RFC4895, section 6.3. Receiving Authenticated Chunks says:

  The receiver MUST use the HMAC algorithm indicated in
  the HMAC Identifier field. If this algorithm was not
  specified by the receiver in the HMAC-ALGO parameter in
  the INIT or INIT-ACK chunk during association setup, the
  AUTH chunk and all the chunks after it MUST be discarded
  and an ERROR chunk SHOULD be sent with the error cause
  defined in Section 4.1. [...] If no endpoint pair shared
  key has been configured for that Shared Key Identifier,
  all authenticated chunks MUST be silently discarded. [...]

  When an endpoint requires COOKIE-ECHO chunks to be
  authenticated, some special procedures have to be followed
  because the reception of a COOKIE-ECHO chunk might result
  in the creation of an SCTP association. If a packet arrives
  containing an AUTH chunk as a first chunk, a COOKIE-ECHO
  chunk as the second chunk, and possibly more chunks after
  them, and the receiver does not have an STCB for that
  packet, then authentication is based on the contents of
  the COOKIE-ECHO chunk. In this situation, the receiver MUST
  authenticate the chunks in the packet by using the RANDOM
  parameters, CHUNKS parameters and HMAC_ALGO parameters
  obtained from the COOKIE-ECHO chunk, and possibly a local
  shared secret as inputs to the authentication procedure
  specified in Section 6.3. If authentication fails, then
  the packet is discarded. If the authentication is successful,
  the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
  MUST be processed. If the receiver has an STCB, it MUST
  process the AUTH chunk as described above using the STCB
  from the existing association to authenticate the
  COOKIE-ECHO chunk and all the chunks after it. [...]

Commit bbd0d59809f9 introduced the possibility to receive
and verification of AUTH chunk, including the edge case for
authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
the function sctp_sf_do_5_1D_ce() handles processing,
unpacks and creates a new association if it passed sanity
checks and also tests for authentication chunks being
present. After a new association has been processed, it
invokes sctp_process_init() on the new association and
walks through the parameter list it received from the INIT
and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
meta data (peer_random, peer_hmacs, peer_chunks) in case
sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
peer_random != NULL and peer_hmacs != NULL the peer is to be
assumed asoc->peer.auth_capable=1, in any other case

Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
available, we set up a fake auth chunk and pass that on to
sctp_sf_authenticate(), which at latest in
sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
at position 0..0008 when setting up the crypto key in
crypto_hash_setkey() by using asoc->asoc_shared_key that is
NULL as condition key_id == asoc->active_key_id is true if
the AUTH chunk was injected correctly from remote. This
happens no matter what net.sctp.auth_enable sysctl says.

The fix is to check for net->sctp.auth_enable and for
asoc->peer.auth_capable before doing any operations like
sctp_sf_authenticate() as no key is activated in
sctp_auth_asoc_init_active_key() for each case.

Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
passed from the INIT chunk was not used in the AUTH chunk, we
SHOULD send an error; however in this case it would be better
to just silently discard such a maliciously prepared handshake
as we didn't even receive a parameter at all. Also, as our
endpoint has no shared key configured, section 6.3 says that
MUST silently discard, which we are doing from now onwards.

Before calling sctp_sf_pdiscard(), we need not only to free
the association, but also the chunk->auth_chunk skb, as
commit bbd0d59809f9 created a skb clone in that case.

I have tested this locally by using netfilter's nfqueue and
re-injecting packets into the local stack after maliciously
modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
and the SCTP packet containing the COOKIE_ECHO (injecting
AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.

Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk")
Signed-off-by: Daniel Borkmann <>
Cc: Vlad Yasevich <>
Cc: Neil Horman <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agotg3: Don't check undefined error bits in RXBD
Michael Chan [Fri, 28 Feb 2014 23:05:10 +0000 (15:05 -0800)]
tg3: Don't check undefined error bits in RXBD

[ Upstream commit d7b95315cc7f441418845a165ee56df723941487 ]

Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
a customer reported issue of randomly dropping packets on the 5719.

Signed-off-by: Michael Chan <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agovirtio-net: alloc big buffers also when guest can receive UFO
Jason Wang [Fri, 21 Feb 2014 05:08:04 +0000 (13:08 +0800)]
virtio-net: alloc big buffers also when guest can receive UFO

[ Upstream commit 0e7ede80d929ff0f830c44a543daa1acd590c749 ]

We should alloc big buffers also when guest can receive UFO
packets to let the big packets fit into guest rx buffer.

Fixes 5c5167515d80f78f6bb538492c423adcae31ad65
(virtio-net: Allow UFO feature to be set and advertised.)

Cc: Rusty Russell <>
Cc: Michael S. Tsirkin <>
Cc: Sridhar Samudrala <>
Signed-off-by: Jason Wang <>
Acked-by: Michael S. Tsirkin <>
Acked-by: Rusty Russell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agojiffies: Avoid undefined behavior from signed overflow
Paul E. McKenney [Sat, 27 Jul 2013 10:53:54 +0000 (03:53 -0700)]
jiffies: Avoid undefined behavior from signed overflow

commit 5a581b367b5df0531265311fc681c2abd377e5e6 upstream.

According to the C standard 3.4.3p3, overflow of a signed integer results
in undefined behavior.  This commit therefore changes the definitions
of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
to avoid this undefined behavior.  The trick is that the subtraction
is done using unsigned arithmetic, which according to 6.2.5p9 cannot
overflow because it is defined as modulo arithmetic.  This has the added
(though admittedly quite small) benefit of shortening four lines of code
by four characters each.

Note that the C standard considers the cast from unsigned to
signed to be implementation-defined, see  However, on a
two's-complement system, an implementation that defines anything other
than a reinterpretation of the bits is free to come to me, and I will be
happy to act as a witness for its being committed to an insane asylum.
(Although I have nothing against saturating arithmetic or signals in some
cases, these things really should not be the default when compiling an
operating-system kernel.)

Signed-off-by: Paul E. McKenney <>
Cc: John Stultz <>
Cc: "David S. Miller" <>
Cc: Arnd Bergmann <>
Cc: Ingo Molnar <>
Cc: Linus Torvalds <>
Cc: Eric Dumazet <>
Cc: Kevin Easton <>
[ paulmck: Included time_after64() and time_after_eq64(), as suggested
  by Eric Dumazet, also fixed commit message.]
Reviewed-by: Josh Triplett <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: oxygen: Xonar DG(X): modify DAC routing
Clemens Ladisch [Wed, 5 Mar 2014 21:16:17 +0000 (22:16 +0100)]
ALSA: oxygen: Xonar DG(X): modify DAC routing

commit 1f91ecc14deea9461aca93273d78871ec4d98fcd upstream.

When selecting the audio output destinations (headphones, FP headphones,
multichannel output), unnecessary I2S channels are digitally muted to
avoid invalid signal levels on the other outputs.

Signed-off-by: Roman Volkov <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2
Roman Volkov [Fri, 24 Jan 2014 12:18:14 +0000 (16:18 +0400)]
ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2

commit 3dd77654fb1d7f68b9739f3039bad8dbbc0739f8 upstream.

Actually CS4245 connected to the I2S channel 1 for
capture, not channel 2. Otherwise capturing and
playback does not work for CS4245.

Signed-off-by: Roman Volkov <>
Signed-off-by: Clemens Ladisch <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agosaa7134: Fix unlocked snd_pcm_stop() call
Takashi Iwai [Thu, 11 Jul 2013 16:00:59 +0000 (18:00 +0200)]
saa7134: Fix unlocked snd_pcm_stop() call

commit e6355ad7b1c6f70e2f48ae159f5658b441ccff95 upstream.

snd_pcm_stop() must be called in the PCM substream lock context.

Signed-off-by: Takashi Iwai <>
[wml: Backported to 3.4: Adjust filename]
Signed-off-by: Weng Meiling <>
Signed-off-by: Ben Hutchings <>
7 years agocifs: set MAY_SIGN when sec=krb5
Martijn de Gouw [Wed, 24 Oct 2012 09:45:46 +0000 (11:45 +0200)]
cifs: set MAY_SIGN when sec=krb5

commit 0b7bc84000d71f3647ca33ab1bf5bd928535c846 upstream.

Setting this secFlg allows usage of dfs where some servers require
signing and others don't.

Signed-off-by: Martijn de Gouw <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
[Joseph Salisbury: This backport was done so including mainline commit
8830d7e07a5e38bc47650a7554b7c1cfd49902bf is not needed.]
Signed-off-by: Joseph Salisbury <>
Signed-off-by: Ben Hutchings <>
7 years agonet: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
Daniel Borkmann [Mon, 17 Feb 2014 11:11:11 +0000 (12:11 +0100)]
net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode

[ Upstream commit ffd5939381c609056b33b7585fb05a77b4c695f3 ]

SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
sizeof(param) check will always fail in kernel as the structure in
64bit kernel space is 4bytes larger than for user binaries compiled
in 32bit mode. Thus, applications making use of sctp_connectx() won't
be able to run under such circumstances.

Introduce a compat interface in the kernel to deal with such
situations by using a 'struct compat_sctp_getaddrs_old' structure
where user data is copied into it, and then sucessively transformed
into a 'struct sctp_getaddrs_old' structure with the help of
compat_ptr(). That fixes sctp_connectx() abi without any changes
needed in user space, and lets the SCTP test suite pass when compiled
in 32bit and run on 64bit kernels.

Fixes: f9c67811ebc0 ("sctp: Fix regression introduced by new sctp_connectx api")
Signed-off-by: Daniel Borkmann <>
Acked-by: Neil Horman <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agobonding: 802.3ad: make aggregator_identifier bond-private
Jiri Bohac [Fri, 14 Feb 2014 17:13:50 +0000 (18:13 +0100)]
bonding: 802.3ad: make aggregator_identifier bond-private

[ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]

aggregator_identifier is used to assign unique aggregator identifiers
to aggregators of a bond during device enslaving.

aggregator_identifier is currently a global variable that is zeroed in

This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:

create bond0
change bond0 mode to 802.3ad
enslave eth0 to bond0  //eth0 gets agg id 1
enslave eth1 to bond0  //eth1 gets agg id 2
create bond1
change bond1 mode to 802.3ad
enslave eth2 to bond1 //aggregator_identifier is reset to 0
//eth2 gets agg id 1
enslave eth3 to bond0  //eth3 gets agg id 2

Fix this by making aggregator_identifier private to the bond.

Signed-off-by: Jiri Bohac <>
Acked-by: Veaceslav Falico <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agousbnet: remove generic hard_header_len check
Emil Goode [Thu, 13 Feb 2014 16:50:19 +0000 (17:50 +0100)]
usbnet: remove generic hard_header_len check

[ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]

This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.

One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.

With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.

The bug has been reported here:

This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
  function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
  within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
  callback function that could be affected by this change.
  These extra checks could possibly be removed by someone
  who has the hardware to test.
- Removes a call to dev_kfree_skb_any() and instead utilizes the
  dev->done list to queue skbs for cleanup.

The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.

Signed-off-by: Emil Goode <>
Reported-by: Igor Gnatenko <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agotg3: Fix deadlock in tg3_change_mtu()
Nithin Sujir [Thu, 6 Feb 2014 22:13:05 +0000 (14:13 -0800)]
tg3: Fix deadlock in tg3_change_mtu()

[ Upstream commit c6993dfd7db9b0c6b7ca7503a56fda9236a4710f ]

Quoting David Vrabel -
"5780 cards cannot have jumbo frames and TSO enabled together.  When
jumbo frames are enabled by setting the MTU, the TSO feature must be
cleared.  This is done indirectly by calling netdev_update_features()
which will call tg3_fix_features() to actually clear the flags.

netdev_update_features() will also trigger a new netlink message for the
feature change event which will result in a call to tg3_get_stats64()
which deadlocks on the tg3 lock."

tg3_set_mtu() does not need to be under the tg3 lock since converting
the flags to use set_bit(). Move it out to after tg3_netif_stop().

Reported-by: David Vrabel <>
Tested-by: David Vrabel <>
Signed-off-by: Michael Chan <>
Signed-off-by: Nithin Nayak Sujir <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: fix 'ip rule' iif/oif device rename
Maciej Żenczykowski [Sat, 8 Feb 2014 00:23:48 +0000 (16:23 -0800)]
net: fix 'ip rule' iif/oif device rename

[ Upstream commit 946c032e5a53992ea45e062ecb08670ba39b99e3 ]

ip rules with iif/oif references do not update:
(detach/attach) across interface renames.

Signed-off-by: Maciej Żenczykowski <>
CC: Willem de Bruijn <>
CC: Eric Dumazet <>
CC: Chris Davis <>
CC: Carlo Contavalli <>
Google-Bug-Id: 12936021
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoprintk: Fix scheduling-while-atomic problem in console_cpu_notify()
Paul E. McKenney [Tue, 16 Oct 2012 04:35:59 +0000 (21:35 -0700)]
printk: Fix scheduling-while-atomic problem in console_cpu_notify()

commit 85eae82a0855d49852b87deac8653e4ebc8b291f upstream.

The console_cpu_notify() function runs with interrupts disabled in the
CPU_DYING case.  It therefore cannot block, for example, as will happen
when it calls console_lock().  Therefore, remove the CPU_DYING leg of
the switch statement to avoid this problem.

Signed-off-by: Paul E. McKenney <>
Reviewed-by: Srivatsa S. Bhat <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agotimekeeping: fix 32-bit overflow in get_monotonic_boottime
Colin Cross [Mon, 10 Feb 2014 21:16:29 +0000 (13:16 -0800)]
timekeeping: fix 32-bit overflow in get_monotonic_boottime

fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c

get_monotonic_boottime adds three nanonsecond values stored
in longs, followed by an s64.  If the long values are all
close to 1e9 the first three additions can overflow and
become negative when added to the s64.  Cast the first
value to s64 so that all additions are 64 bit.

Signed-off-by: Colin Cross <>
[jstultz: Fished this out of the AOSP commong.git tree. This was
fixed upstream in v3.6 by ec145babe754f9ea1079034a108104b6001e001c]
Signed-off-by: John Stultz <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoftrace: Have function graph only trace based on global_ops filters
Steven Rostedt [Tue, 11 Feb 2014 19:50:01 +0000 (14:50 -0500)]
ftrace: Have function graph only trace based on global_ops filters

commit 23a8e8441a0a74dd612edf81dc89d1600bc0a3d1 upstream.

Doing some different tests, I discovered that function graph tracing, when
filtered via the set_ftrace_filter and set_ftrace_notrace files, does
not always keep with them if another function ftrace_ops is registered
to trace functions.

The reason is that function graph just happens to trace all functions
that the function tracer enables. When there was only one user of
function tracing, the function graph tracer did not need to worry about
being called by functions that it did not want to trace. But now that there
are other users, this becomes a problem.

For example, one just needs to do the following:

 # cd /sys/kernel/debug/tracing
 # echo schedule > set_ftrace_filter
 # echo function_graph > current_tracer
 # cat trace
 0)               |  schedule() {
 0)    <idle>-0    =>   rcu_pre-7

 0) ! 2980.314 us |  }
 0)               |  schedule() {
 0)   rcu_pre-7    =>    <idle>-0

 0) + 20.701 us   |  }

 # echo 1 > /proc/sys/kernel/stack_tracer_enabled
 # cat trace
 1) + 20.825 us   |      }
 1) + 21.651 us   |    }
 1) + 30.924 us   |  } /* SyS_ioctl */
 1)               |  do_page_fault() {
 1)               |    __do_page_fault() {
 1)   0.274 us    |      down_read_trylock();
 1)   0.098 us    |      find_vma();
 1)               |      handle_mm_fault() {
 1)               |        _raw_spin_lock() {
 1)   0.102 us    |          preempt_count_add();
 1)   0.097 us    |          do_raw_spin_lock();
 1)   2.173 us    |        }
 1)               |        do_wp_page() {
 1)   0.079 us    |          vm_normal_page();
 1)   0.086 us    |          reuse_swap_page();
 1)   0.076 us    |          page_move_anon_rmap();
 1)               |          unlock_page() {
 1)   0.082 us    |            page_waitqueue();
 1)   0.086 us    |            __wake_up_bit();
 1)   1.801 us    |          }
 1)   0.075 us    |          ptep_set_access_flags();
 1)               |          _raw_spin_unlock() {
 1)   0.098 us    |            do_raw_spin_unlock();
 1)   0.105 us    |            preempt_count_sub();
 1)   1.884 us    |          }
 1)   9.149 us    |        }
 1) + 13.083 us   |      }
 1)   0.146 us    |      up_read();

When the stack tracer was enabled, it enabled all functions to be traced, which
now the function graph tracer also traces. This is a side effect that should
not occur.

To fix this a test is added when the function tracing is changed, as well as when
the graph tracer is enabled, to see if anything other than the ftrace global_ops
function tracer is enabled. If so, then the graph tracer calls a test trampoline
that will look at the function that is being traced and compare it with the
filters defined by the global_ops.

As an optimization, if there's no other function tracers registered, or if
the only registered function tracers also use the global ops, the function
graph infrastructure will call the registered function graph callback directly
and not go through the test trampoline.

Fixes: d2d45c7a03a2 "tracing: Have stack_tracer use a separate list of functions"
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agohpfs: deadlock and race in directory lseek()
Al Viro [Sat, 18 May 2013 06:38:52 +0000 (02:38 -0400)]
hpfs: deadlock and race in directory lseek()

commit 31abdab9c11bb1694ecd1476a7edbe8e964d94ac upstream.

For one thing, there's an ABBA deadlock on hpfs fs-wide lock and i_mutex
in hpfs_dir_lseek() - there's a lot of methods that grab the former with
the caller already holding the latter, so it must take i_mutex first.

For another, locking the damn thing, carefully validating the offset,
then dropping locks and assigning the offset is obviously racy.

Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
won't modify the sucker on B-tree surgeries.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
7 years agohpfs: remember free space
Mikulas Patocka [Tue, 28 Jan 2014 23:10:44 +0000 (00:10 +0100)]
hpfs: remember free space

commit 2cbe5c76fc5e38e9af4b709593146e4b8272b69e upstream.

Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs.  This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.

New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.

This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Linus Torvalds <>
[ kamal: backport to 3.8 (no hpfs_prefetch_bitmap) ]
Signed-off-by: Kamal Mostafa <>
Signed-off-by: Ben Hutchings <>
7 years agoTTY: pmac_zilog, check existence of ports in pmz_console_init()
Geert Uytterhoeven [Fri, 22 Nov 2013 15:47:26 +0000 (16:47 +0100)]
TTY: pmac_zilog, check existence of ports in pmz_console_init()

commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream.

When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0"
on the kernel command line, it crashes with:

Unable to handle kernel NULL pointer dereference at virtual address   (null)
Oops: 00000000
PC: [<0013ad28>] __pmz_startup+0x32/0x2a0
Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4

The normal tty driver doesn't crash, because init_pmz() checks
pmz_ports_count again after calling pmz_probe().

In the serial console initialization path, pmz_console_init() doesn't do
this, causing the driver to crash later.

Add a check for pmz_ports_count to fix this.

Signed-off-by: Geert Uytterhoeven <>
Cc: Finn Thain <>
Cc: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agomm/hugetlb: check for pte NULL pointer in __page_check_address()
Jianguo Wu [Thu, 19 Dec 2013 01:08:59 +0000 (17:08 -0800)]
mm/hugetlb: check for pte NULL pointer in __page_check_address()

commit 98398c32f6687ee1e1f3ae084effb4b75adb0747 upstream.

In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.

Signed-off-by: Jianguo Wu <>
Cc: Naoya Horiguchi <>
Cc: Mel Gorman <>
Cc: qiuxishi <>
Cc: Hanjun Guo <>
Acked-by: Kirill A. Shutemov <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agonfs: fix do_div() warning by instead using sector_div()
Helge Deller [Mon, 2 Dec 2013 18:59:31 +0000 (19:59 +0100)]
nfs: fix do_div() warning by instead using sector_div()

commit 3873d064b8538686bbbd4b858dc8a07db1f7f43a upstream.

When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like
shown below.  Fix this warning by instead using sector_div() which is provided
by the kernel.h header file.

fs/nfs/blocklayout/extents.c: In function ‘normalize’:
include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’
nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default]
fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default]
include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);

Signed-off-by: Helge Deller <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
7 years agostaging: comedi: pcmuio: fix possible NULL deref on detach
Ian Abbott [Tue, 20 Aug 2013 10:50:19 +0000 (11:50 +0100)]
staging: comedi: pcmuio: fix possible NULL deref on detach

commit 2fd2bdfccae61efe18f6b92b6a45fbf936d75b48 upstream.

pcmuio_detach() is called by the comedi core even if pcmuio_attach()
returned an error, so `dev->private` might be `NULL`.  Check for that
before dereferencing it.

Also, as pointed out by Dan Carpenter, there is no need to check the
pointer passed to `kfree()` is non-NULL, so remove that check.

Signed-off-by: Ian Abbott <>
Cc: Dan Carpenter <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agostaging: comedi: ssv_dnp: correct insn_bits result
Ian Abbott [Thu, 12 Dec 2013 11:32:19 +0000 (11:32 +0000)]
staging: comedi: ssv_dnp: correct insn_bits result

[Part of commit f6b316bcd8c421acd6fa5a6e18b4c846ecb9d965 upstream.
Split from original patch subject: "staging: comedi: ssv_dnp: use

Also, fix a bug where the state of the channels is returned in data[0].
The comedi core expects it to be returned in data[1].

Signed-off-by: Ian Abbott <>
Signed-off-by: Ben Hutchings <>
7 years agox86/amd/numa: Fix northbridge quirk to assign correct NUMA node
Daniel J Blueman [Thu, 13 Mar 2014 11:43:01 +0000 (19:43 +0800)]
x86/amd/numa: Fix northbridge quirk to assign correct NUMA node

commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream.

For systems with multiple servers and routed fabric, all
northbridges get assigned to the first server. Fix this by also
using the node reported from the PCI bus. For single-fabric
systems, the northbriges are on PCI bus 0 by definition, which
are on NUMA node 0 by definition, so this is invarient on most

Tested on fam10h and fam15h single and multi-fabric systems and
candidate for stable.

Signed-off-by: Daniel J Blueman <>
Acked-by: Steffen Persvold <>
Acked-by: Borislav Petkov <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agovmxnet3: fix building without CONFIG_PCI_MSI
Arnd Bergmann [Thu, 13 Mar 2014 09:44:34 +0000 (10:44 +0100)]
vmxnet3: fix building without CONFIG_PCI_MSI

commit 0a8d8c446b5429d15ff2d48f46e00d8a08552303 upstream.

Since commit d25f06ea466e "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()

To fix this, use the same #ifdef in the caller that exists around
the function definition.

Signed-off-by: Arnd Bergmann <>
Cc: Neil Horman <>
Cc: Shreyas Bhatewara <>
Cc: "VMware, Inc." <>
Cc: "David S. Miller" <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: SVM: fix cr8 intercept window
Radim Krčmář [Tue, 11 Mar 2014 18:11:18 +0000 (19:11 +0100)]
KVM: SVM: fix cr8 intercept window

commit 596f3142d2b7be307a1652d59e7b93adab918437 upstream.

We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.

Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.

Signed-off-by: Radim Krčmář <>
Reviewed-by: Marcelo Tosatti <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agovmxnet3: fix netpoll race condition
Neil Horman [Mon, 10 Mar 2014 10:55:55 +0000 (06:55 -0400)]
vmxnet3: fix netpoll race condition

commit d25f06ea466ea521b563b76661180b4e44714ae6 upstream.

vmxnet3's netpoll driver is incorrectly coded.  It directly calls
vmxnet3_do_poll, which is the driver internal napi poll routine.  As the netpoll
controller method doesn't block real napi polls in any way, there is a potential
for race conditions in which the netpoll controller method and the napi poll
method run concurrently.  The result is data corruption causing panics such as this
one recently observed:
PID: 1371   TASK: ffff88023762caa0  CPU: 1   COMMAND: "rs:main Q:Reg"
 #0 [ffff88023abd5780] machine_kexec at ffffffff81038f3b
 #1 [ffff88023abd57e0] crash_kexec at ffffffff810c5d92
 #2 [ffff88023abd58b0] oops_end at ffffffff8152b570
 #3 [ffff88023abd58e0] die at ffffffff81010e0b
 #4 [ffff88023abd5910] do_trap at ffffffff8152add4
 #5 [ffff88023abd5970] do_invalid_op at ffffffff8100cf95
 #6 [ffff88023abd5a10] invalid_op at ffffffff8100bf9b
    [exception RIP: vmxnet3_rq_rx_complete+1968]
    RIP: ffffffffa00f1e80  RSP: ffff88023abd5ac8  RFLAGS: 00010086
    RAX: 0000000000000000  RBX: ffff88023b5dcee0  RCX: 00000000000000c0
    RDX: 0000000000000000  RSI: 00000000000005f2  RDI: ffff88023b5dcee0
    RBP: ffff88023abd5b48   R8: 0000000000000000   R9: ffff88023a3b6048
    R10: 0000000000000000  R11: 0000000000000002  R12: ffff8802398d4cd8
    R13: ffff88023af35140  R14: ffff88023b60c890  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff88023abd5b50] vmxnet3_do_poll at ffffffffa00f204a [vmxnet3]
 #8 [ffff88023abd5b80] vmxnet3_netpoll at ffffffffa00f209c [vmxnet3]
 #9 [ffff88023abd5ba0] netpoll_poll_dev at ffffffff81472bb7

The fix is to do as other drivers do, and have the poll controller call the top
half interrupt handler, which schedules a napi poll properly to recieve frames

Tested by myself, successfully.

Signed-off-by: Neil Horman <>
CC: Shreyas Bhatewara <>
CC: "VMware, Inc." <>
CC: "David S. Miller" <>
Reviewed-by: Shreyas N Bhatewara <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoocfs2 syncs the wrong range...
Al Viro [Mon, 10 Feb 2014 20:18:55 +0000 (15:18 -0500)]
ocfs2 syncs the wrong range...

commit 1b56e98990bcdbb20b9fab163654b9315bf158e8 upstream.

Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
7 years agoqla2xxx: Poll during initialization for ISP25xx and ISP83xx
Giridhar Malavali [Wed, 26 Feb 2014 09:15:12 +0000 (04:15 -0500)]
qla2xxx: Poll during initialization for ISP25xx and ISP83xx

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.

Signed-off-by: Giridhar Malavali <>
Signed-off-by: Saurav Kashyap <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2:
 - Adjust context
 - QLA83XX was not included]
Signed-off-by: Ben Hutchings <>
7 years agoisci: correct erroneous for_each_isci_host macro
Lukasz Dorau [Thu, 6 Feb 2014 20:23:20 +0000 (12:23 -0800)]
isci: correct erroneous for_each_isci_host macro

commit c59053a23d586675c25d789a7494adfdc02fba57 upstream.

In the first place, the loop 'for' in the macro 'for_each_isci_host'
(drivers/scsi/isci/host.h:314) is incorrect, because it accesses
the 3rd element of 2 element array. After the 2nd iteration it executes
the instruction:
        ihost = to_pci_info(pdev)->hosts[2]
(while the size of the 'hosts' array equals 2) and reads an
out of range element.

In the second place, this loop is incorrectly optimized by GCC v4.8
As a result, on platforms with two SCU controllers,
the loop is executed more times than it can be (for i=0,1 and 2).
It causes kernel panic during entering the S3 state
and the following oops after 'rmmod isci':

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff8131360b>] __list_add+0x1b/0xc0
Oops: 0000 [#1] SMP
RIP: 0010:[<ffffffff8131360b>]  [<ffffffff8131360b>] __list_add+0x1b/0xc0
Call Trace:
  [<ffffffff81661b84>] __mutex_lock_slowpath+0x114/0x1b0
  [<ffffffff81661c3f>] mutex_lock+0x1f/0x30
  [<ffffffffa03e97cb>] sas_disable_events+0x1b/0x50 [libsas]
  [<ffffffffa03e9818>] sas_unregister_ha+0x18/0x60 [libsas]
  [<ffffffffa040316e>] isci_unregister+0x1e/0x40 [isci]
  [<ffffffffa0403efd>] isci_pci_remove+0x5d/0x100 [isci]
  [<ffffffff813391cb>] pci_device_remove+0x3b/0xb0
  [<ffffffff813fbf7f>] __device_release_driver+0x7f/0xf0
  [<ffffffff813fc8f8>] driver_detach+0xa8/0xb0
  [<ffffffff813fbb8b>] bus_remove_driver+0x9b/0x120
  [<ffffffff813fcf2c>] driver_unregister+0x2c/0x50
  [<ffffffff813381f3>] pci_unregister_driver+0x23/0x80
  [<ffffffffa04152f8>] isci_exit+0x10/0x1e [isci]
  [<ffffffff810d199b>] SyS_delete_module+0x16b/0x2d0
  [<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0
  [<ffffffff8166ce29>] system_call_fastpath+0x16/0x1b

The loop has been corrected.
This patch fixes kernel panic during entering the S3 state
and the above oops.

Signed-off-by: Lukasz Dorau <>
Reviewed-by: Maciej Patelczyk <>
Tested-by: Lukasz Dorau <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agoisci: fix reset timeout handling
Dan Williams [Thu, 6 Feb 2014 20:23:01 +0000 (12:23 -0800)]
isci: fix reset timeout handling

commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.

Remove an erroneous BUG_ON() in the case of a hard reset timeout.  The
reset timeout handler puts the port into the "awaiting link-up" state.
The timeout causes the device to be disconnected and we need to be in
the awaiting link-up state to re-connect the port.  The BUG_ON() made
the incorrect assumption that resets never timeout and we always
complete the reset in the "resetting" state.

Testing this patch also uncovered that libata continues to attempt to
reset the port long after the driver has torn down the context.  Once
the driver has committed to abandoning the link it must indicate to
libata that recovery ends by returning -ENODEV from

Acked-by: Lukasz Dorau <>
Reported-by: David Milburn <>
Reported-by: Xun Ni <>
Tested-by: Xun Ni <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
Julius Werner [Tue, 4 Mar 2014 19:27:38 +0000 (11:27 -0800)]
usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests

commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream.

The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.

Signed-off-by: Julius Werner <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agousb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
Julius Werner [Tue, 4 Mar 2014 18:52:39 +0000 (10:52 -0800)]
usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e

commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream.

We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.

Signed-off-by: Julius Werner <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agolibata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 ...
Michele Baldessari [Fri, 7 Mar 2014 16:34:29 +0000 (16:34 +0000)]
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)

commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream.

Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".

As reported on,
we need to also add firmware revision 2BA30001 as it is broken as well.

Reported-by: Nicholas <>
Signed-off-by: Michele Baldessari <>
Tested-by: Guilherme Amadio <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agopowerpc: Align p_dyn, p_rela and p_st symbols
Anton Blanchard [Mon, 3 Mar 2014 21:31:24 +0000 (08:31 +1100)]
powerpc: Align p_dyn, p_rela and p_st symbols

commit a5b2cf5b1af424ee3dd9e3ce6d5cea18cb927e67 upstream.

The 64bit relocation code places a few symbols in the text segment.
These symbols are only 4 byte aligned where they need to be 8 byte
aligned. Add an explicit alignment.

Signed-off-by: Anton Blanchard <>
Tested-by: Laurent Dufour <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
7 years agonet: unix socket code abuses csum_partial
Anton Blanchard [Wed, 5 Mar 2014 03:29:58 +0000 (14:29 +1100)]
net: unix socket code abuses csum_partial

commit 0a13404dd3bf4ea870e3d96270b5a382edca85c0 upstream.

The unix socket code is using the result of csum_partial to
hash into a lookup table:

unix_hash_fold(csum_partial(sunaddr, len, 0));

csum_partial is only guaranteed to produce something that can be
folded into a checksum, as its prototype explains:

 * returns a 32-bit number suitable for feeding into itself
 * or csum_tcpudp_magic

The 32bit value should not be used directly.

Depending on the alignment, the ppc64 csum_partial will return
different 32bit partial checksums that will fold into the same
16bit checksum.

This difference causes the following testcase (courtesy of
Gustavo) to sometimes fail:

#include <sys/socket.h>
#include <stdio.h>

int main()

int i = 1;
setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &i, 4);

struct sockaddr addr;
addr.sa_family = AF_LOCAL;
bind(fd, &addr, 2);

listen(fd, 128);

struct sockaddr_storage ss;
socklen_t sslen = (socklen_t)sizeof(ss);
getsockname(fd, (struct sockaddr*)&ss, &sslen);


if (connect(fd, (struct sockaddr*)&ss, sslen) == -1){
return 1;
return 0;

As suggested by davem, fix this by using csum_fold to fold the
partial 32bit checksum into a 16bit checksum before using it.

Signed-off-by: Anton Blanchard <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomwifiex: copy AP's HT capability info correctly
Amitkumar Karwar [Wed, 5 Mar 2014 02:43:13 +0000 (18:43 -0800)]
mwifiex: copy AP's HT capability info correctly

commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream.

While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.

This patch fixes an error while copying this field from AP's

Signed-off-by: Amitkumar Karwar <>
Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
7 years agomac80211: clear sequence/fragment number in QoS-null frames
Johannes Berg [Tue, 4 Mar 2014 12:46:53 +0000 (13:46 +0100)]
mac80211: clear sequence/fragment number in QoS-null frames

commit 864a6040f395464003af8dd0d8ca86fed19866d4 upstream.

Avoid leaking data by sending uninitialized memory and setting an
invalid (non-zero) fragment number (the sequence number is ignored
anyway) by setting the seq_ctrl field to zero.

Fixes: 3f52b7e328c5 ("mac80211: mesh power save basics")
Fixes: ce662b44ce22 ("mac80211: send (QoS) Null if no buffered frames")
Reviewed-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: Drop change to mps_qos_null_get()]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: usb-audio: Add quirk for Logitech Webcam C500
Takashi Iwai [Wed, 5 Mar 2014 11:34:39 +0000 (12:34 +0100)]
ALSA: usb-audio: Add quirk for Logitech Webcam C500

commit e805ca8b0a9b6c91099c0eaa4b160a1196a4ae25 upstream.

Logitech C500 (046d:0807) needs the same workaround like other
Logitech Webcams.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoocfs2: fix quota file corruption
Jan Kara [Mon, 3 Mar 2014 23:38:32 +0000 (15:38 -0800)]
ocfs2: fix quota file corruption

commit 15c34a760630ca2c803848fba90ca0646a9907dd upstream.

Global quota files are accessed from different nodes.  Thus we cannot
cache offset of quota structure in the quota file after we drop our node
reference count to it because after that moment quota structure may be
freed and reallocated elsewhere by a different node resulting in
corruption of quota file.

Fix the problem by clearing dq_off when we are releasing dquot structure.
We also remove the DB_READ_B handling because it is useless -
DQ_ACTIVE_B is set iff DQ_READ_B is set.

Signed-off-by: Jan Kara <>
Cc: Goldwyn Rodrigues <>
Cc: Joel Becker <>
Reviewed-by: Mark Fasheh <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agotracing: Do not add event files for modules that fail tracepoints
Steven Rostedt (Red Hat) [Wed, 26 Feb 2014 18:37:38 +0000 (13:37 -0500)]
tracing: Do not add event files for modules that fail tracepoints

commit 45ab2813d40d88fc575e753c38478de242d03f88 upstream.

If a module fails to add its tracepoints due to module tainting, do not
create the module event infrastructure in the debugfs directory. As the events
will not work and worse yet, they will silently fail, making the user wonder
why the events they enable do not display anything.

Having a warning on module load and the events not visible to the users
will make the cause of the problem much clearer.

Fixes: 6d723736e472 "tracing/events: add support for modules to TRACE_EVENT"
Acked-by: Mathieu Desnoyers <>
Cc: Rusty Russell <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
7 years agocan: flexcan: flexcan_remove(): add missing netif_napi_del()
Marc Kleine-Budde [Fri, 28 Feb 2014 19:48:36 +0000 (20:48 +0100)]
can: flexcan: flexcan_remove(): add missing netif_napi_del()

commit d96e43e8fce28cf97df576a07af9d65657a41a6f upstream.

This patch adds the missing netif_napi_del() to the flexcan_remove() function.

Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agocan: flexcan: flexcan_open(): fix error path if flexcan_chip_start() fails
Marc Kleine-Budde [Fri, 28 Feb 2014 13:52:01 +0000 (14:52 +0100)]
can: flexcan: flexcan_open(): fix error path if flexcan_chip_start() fails

commit 7e9e148af01ef388efb6e2490805970be4622792 upstream.

If flexcan_chip_start() in flexcan_open() fails, the interrupt is not freed,
this patch adds the missing cleanup.

Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agocan: flexcan: fix shutdown: first disable chip, then all interrupts
Marc Kleine-Budde [Wed, 19 Feb 2014 11:00:51 +0000 (12:00 +0100)]
can: flexcan: fix shutdown: first disable chip, then all interrupts

commit 5be93bdda64e85450598c6e97f79fb8f6acf30e0 upstream.

When shutting down the CAN interface (ifconfig canX down) during high CAN bus
loads, the CAN core might hang and freeze the whole CPU.

This patch fixes the shutdown sequence by first disabling the CAN core then
disabling all interrupts.

Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agopowerpc/crashdump : Fix page frame number check in copy_oldmem_page
Laurent Dufour [Mon, 24 Feb 2014 16:30:55 +0000 (17:30 +0100)]
powerpc/crashdump : Fix page frame number check in copy_oldmem_page

commit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.

In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
decide if the page is backed or not, is not valid when the memory layout is
not continuous.

This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
in the memory. In that case max_pfn points to the end of RTAS, and a hole
between the end of the kdump kernel and RTAS is not backed by PTEs. As a
consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
in a direct way the pages in that hole.

This fix relies on the memblock's service memblock_is_region_memory to
check if the read page is part or not of the directly accessible memory.

Signed-off-by: Laurent Dufour <>
Tested-by: Mahesh Salgaonkar <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
7 years agocpuset: fix a race condition in __cpuset_node_allowed_softwall()
Li Zefan [Thu, 27 Feb 2014 10:19:36 +0000 (18:19 +0800)]
cpuset: fix a race condition in __cpuset_node_allowed_softwall()

commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream.

It's not safe to access task's cpuset after releasing task_lock().
Holding callback_mutex won't help.

Signed-off-by: Li Zefan <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agoperf: Fix hotplug splat
Peter Zijlstra [Mon, 24 Feb 2014 11:06:12 +0000 (12:06 +0100)]
perf: Fix hotplug splat

commit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream.

Drew Richardson reported that he could make the kernel go *boom* when hotplugging
while having perf events active.

It turned out that when you have a group event, the code in
__perf_event_exit_context() fails to remove the group siblings from
the context.

We then proceed with destroying and freeing the event, and when you
re-plug the CPU and try and add another event to that CPU, things go
*boom* because you've still got dead entries there.

Reported-by: Drew Richardson <>
Signed-off-by: Peter Zijlstra <>
Cc: Will Deacon <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agoperf/x86: Fix event scheduling
Peter Zijlstra [Fri, 21 Feb 2014 15:03:12 +0000 (16:03 +0100)]
perf/x86: Fix event scheduling

commit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.

Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
with perf WARN_ON()s triggering. He also provided traces of the failures.

This is I think the relevant bit:

>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_disable: x86_pmu_disable
>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_state: Events: {
>    pec_1076_warn-2804  [000] d...   147.926156: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
>    pec_1076_warn-2804  [000] d...   147.926158: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
>    pec_1076_warn-2804  [000] d...   147.926159: x86_pmu_state: }
>    pec_1076_warn-2804  [000] d...   147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1
>    pec_1076_warn-2804  [000] d...   147.926161: x86_pmu_state: Assignment: {
>    pec_1076_warn-2804  [000] d...   147.926162: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
>    pec_1076_warn-2804  [000] d...   147.926163: x86_pmu_state: }
>    pec_1076_warn-2804  [000] d...   147.926166: collect_events: Adding event: 1 (ffff880119ec8800)

So we add the insn:p event (fd[23]).

At this point we should have:

  n_events = 2, n_added = 1, n_txn = 1

>    pec_1076_warn-2804  [000] d...   147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)
>    pec_1076_warn-2804  [000] d...   147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)

We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
that's not visible.

  pmu->start_txn() /* nop - BP pmu */

So here we should end up with:

  0: n_events = 3, n_added = 2, n_txn = 2
  4: n_events = 4, n_added = 3, n_txn = 3

But seeing the below state on x86_pmu_enable(), the must have failed,
because the 0 and 4 events aren't there anymore.

Looking at group_sched_in(), since the BP is the leader, its
event_sched_in() must have succeeded, for otherwise we would not have
seen the sibling adds.

But since neither 0 or 4 are in the below state; their event_sched_in()
must have failed; but I don't see why, the complete state: 0,0,1:p,4
fits perfectly fine on a core2.

However, since we try and schedule 4 it means the 0 event must have
succeeded!  Therefore the 4 event must have failed, its failure will
have put group_sched_in() into the fail path, which will call:


on 0 and the BP event.

Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
giving what we see below:

 n_event = 2, n_added = 2, n_txn = 2

>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_enable: x86_pmu_enable
>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_state: Events: {
>    pec_1076_warn-2804  [000] d...   147.926179: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))
>    pec_1076_warn-2804  [000] d...   147.926181: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)
>    pec_1076_warn-2804  [000] d...   147.926182: x86_pmu_state: }
>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2
>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: Assignment: {
>    pec_1076_warn-2804  [000] d...   147.926186: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)
>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state:   1->0 tag: 1 config: 1 (ffff880119ec8800)
>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state: }
>    pec_1076_warn-2804  [000] d...   147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0

So the problem is that x86_pmu_del(), when called from a
group_sched_in() that fails (for whatever reason), and without x86_pmu
TXN support (because the leader is !x86_pmu), will corrupt the n_added

Reported-and-Tested-by: Vince Weaver <>
Signed-off-by: Peter Zijlstra <>
Cc: Paul Mackerras <>
Cc: Steven Rostedt <>
Cc: Stephane Eranian <>
Cc: Dave Jones <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agosched: Fix double normalization of vruntime
George McCollister [Tue, 18 Feb 2014 23:56:51 +0000 (17:56 -0600)]
sched: Fix double normalization of vruntime

commit 791c9e0292671a3bfa95286bb5c08129d8605618 upstream.

dequeue_entity() is called when p->on_rq and sets se->on_rq = 0
which appears to guarentee that the !se->on_rq condition is met.
If the task has done set_current_state(TASK_INTERRUPTIBLE) without
schedule() the second condition will be met and vruntime will be
incorrectly adjusted twice.

In certain cases this can result in the task's vruntime never increasing
past the vruntime of other tasks on the CFS' run queue, starving them of
CPU time.

This patch changes switched_from_fair() to use !p->on_rq instead of

I'm able to cause a task with a priority of 120 to starve all other
tasks with the same priority on an ARM platform running 3.2.51-rt72
PREEMPT RT by writing one character at time to a serial tty (16550 UART)
in a tight loop. I'm also able to verify making this change corrects the
problem on that platform and kernel version.

Signed-off-by: George McCollister <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agogenirq: Remove racy waitqueue_active check
Chuansheng Liu [Mon, 24 Feb 2014 03:29:50 +0000 (11:29 +0800)]
genirq: Remove racy waitqueue_active check

commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream.

We hit one rare case below:

T1 calling disable_irq(), but hanging at synchronize_irq()
The corresponding irq thread is in sleeping state;
And all CPUs are in idle state;

After analysis, we found there is one possible scenerio which
causes T1 is waiting there forever:
CPU0                                       CPU1
      insert the __wait into queue

Here after inserted the __wait into queue on CPU0, and before
test if queue is empty on CPU1, there is no barrier, it maybe
cause it is not visible for CPU1 immediately, although CPU0 has
updated the queue list.
It is similar for CPU0 atomic_read() threads_active also.

So we'd need one smp_mb() before waitqueue_active.that, but removing
the waitqueue_active() check solves it as wel l and it makes
things simple and clear.

Signed-off-by: Chuansheng Liu <>
Cc: Xiaoming Wang <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: The corresponding check is in irq_thread()]
Signed-off-by: Ben Hutchings <>
7 years agoiwlwifi: fix TX status for aggregated packets
Johannes Berg [Tue, 25 Feb 2014 09:37:15 +0000 (10:37 +0100)]
iwlwifi: fix TX status for aggregated packets

commit 143582c6847cb285b361804c613127c25de60ca4 upstream.

Only the first packet is currently handled correctly, but then
all others are assumed to have failed which is problematic. Fix
this, marking them all successful instead (since if they're not
then the firmware will have transmitted them as single frames.)

This fixes the lost packet reporting.

Also do a tiny variable scoping cleanup.

Signed-off-by: Johannes Berg <>
[Add the dvm part]
Signed-off-by: Emmanuel Grumbach <>
[bwh: Backported to 3.2:
 - Drop the mvm part
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agoASoC: sta32x: Fix wrong enum for limiter2 release rate
Takashi Iwai [Thu, 27 Feb 2014 06:41:32 +0000 (07:41 +0100)]
ASoC: sta32x: Fix wrong enum for limiter2 release rate

commit b3619b288b621e63f66908045f48495869a996a6 upstream.

There is a typo in the Limiter2 Release Rate control, a wrong enum for
Limiter1 is assigned.  It must point to Limiter2.
Spotted by a compile warning:

In file included from sound/soc/codecs/sta32x.c:34:0:
sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
 static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
  struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
 static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,

Signed-off-by: Takashi Iwai <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
7 years agousb: ehci: fix deadlock when threadirqs option is used
Stanislaw Gruszka [Wed, 19 Feb 2014 09:29:01 +0000 (10:29 +0100)]
usb: ehci: fix deadlock when threadirqs option is used

commit a1227f3c1030e96ebc51d677d2f636268845c5fb upstream.

ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().

This change can be reverted when hrtimer callbacks become threaded.

Signed-off-by: Stanislaw Gruszka <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: ftdi_sio: add Cressi Leonardo PID
Joerg Dorchain [Fri, 21 Feb 2014 19:29:33 +0000 (20:29 +0100)]
USB: ftdi_sio: add Cressi Leonardo PID

commit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream.


the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.

Signed-off-by: Joerg Dorchain <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: serial: ftdi_sio: add id for Z3X Box device
Алексей Крамаренко [Fri, 1 Nov 2013 13:26:38 +0000 (17:26 +0400)]
USB: serial: ftdi_sio: add id for Z3X Box device

commit e1466ad5b1aeda303f9282463d55798d2eda218c upstream.

Custom VID/PID for Z3X Box device, popular tool for cellphone flashing.

Signed-off-by: Alexey E. Kramarenko <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / processor: Rework processor throttling with work_on_cpu()
Lan Tianyu [Wed, 26 Feb 2014 13:03:05 +0000 (21:03 +0800)]
ACPI / processor: Rework processor throttling with work_on_cpu()

commit f3ca4164529b875374c410193bbbac0ee960895f upstream.

acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
sure that the (struct acpi_processor)->acpi_processor_set_throttling()
callback will run on the right CPU.  However, the function may be
called from a worker thread already bound to a different CPU in which
case that won't work.

Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
instead of abusing set_cpus_allowed_ptr().

Reported-and-tested-by: Jiri Olsa <>
Signed-off-by: Lan Tianyu <>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agoioat: fix tasklet tear down
Dan Williams [Thu, 20 Feb 2014 00:19:35 +0000 (16:19 -0800)]
ioat: fix tasklet tear down

commit da87ca4d4ca101f177fffd84f1f0a5e4c0343557 upstream.

Since commit 77873803363c "net_dma: mark broken" we no longer pin dma
engines active for the network-receive-offload use case.  As a result
the ->free_chan_resources() that occurs after the driver self test no
longer has a NET_DMA induced ->alloc_chan_resources() to back it up.  A
late firing irq can lead to ksoftirqd spinning indefinitely due to the
tasklet_disable() performed by ->free_chan_resources().  Only
->alloc_chan_resources() can clear this condition in affected kernels.

This problem has been present since commit 3e037454bcfa "I/OAT: Add
support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
NET_DMA use case is deprecated we can revisit moving the driver to use
threaded irqs.  For now, just tear down the irq and tasklet properly by:

1/ Disable the irq from triggering the tasklet

2/ Disable the irq from re-arming

3/ Flush inflight interrupts

4/ Flush the timer

5/ Flush inflight tasklets


Cc: Ingo Molnar <>
Cc: Steven Rostedt <>
Reported-by: Mike Galbraith <>
Reported-by: Stanislav Fomichev <>
Tested-by: Mike Galbraith <>
Tested-by: Stanislav Fomichev <>
Reviewed-by: Thomas Gleixner <>
Signed-off-by: Dan Williams <>
[bwh: Backported to 3.2:
 - Adjust context
 - As there is no ioatdma_device::irq_mode member, check
   pci_dev::msix_enabled instead]
Signed-off-by: Ben Hutchings <>
Acked-by: Dan Williams <>
7 years agoi7300_edac: Fix device reference count
Jean Delvare [Tue, 25 Feb 2014 08:43:13 +0000 (09:43 +0100)]
i7300_edac: Fix device reference count

commit 75135da0d68419ef8a925f4c1d5f63d8046e314d upstream.

pci_get_device() decrements the reference count of "from" (last
argument) so when we break off the loop successfully we have only one
device reference - and we don't know which device we have. If we want
a reference to each device, we must take them explicitly and let
the pci_get_device() walk complete to avoid duplicate references.

This is serious, as over-putting device references will cause
the device to eventually disappear. Without this fix, the kernel
crashes after a few insmod/rmmod cycles.

Tested on an Intel S7000FC4UR system with a 7300 chipset.

Signed-off-by: Jean Delvare <>
Cc: Mauro Carvalho Chehab <>
Cc: Doug Thompson <>
Signed-off-by: Borislav Petkov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoi7core_edac: Fix PCI device reference count
Jean Delvare [Mon, 24 Feb 2014 08:39:27 +0000 (09:39 +0100)]
i7core_edac: Fix PCI device reference count

commit c0f5eeed0f4cef4f05b74883a7160e7edde58b6a upstream.

The reference count changes done by pci_get_device can be a little
misleading when the usage diverges from the most common scheme. The
reference count of the device passed as the last parameter is always
decreased, even if the function returns no new device. So if we are
going to try alternative device IDs, we must manually increment the
device reference count before each retry. If we don't, we end up
decreasing the reference count, and after a few modprobe/rmmod cycles
the PCI devices will vanish.

In other words and as Alan put it: without this fix the EDAC code
corrupts the PCI device list.

This fixes kernel bug #50491:

Signed-off-by: Jean Delvare <>
Reviewed-by: Alan Cox <>
Cc: Mauro Carvalho Chehab <>
Cc: Doug Thompson <>
Signed-off-by: Borislav Petkov <>
Signed-off-by: Ben Hutchings <>
7 years agoquota: Fix race between dqput() and dquot_scan_active()
Jan Kara [Thu, 20 Feb 2014 16:02:27 +0000 (17:02 +0100)]
quota: Fix race between dqput() and dquot_scan_active()

commit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream.

Currently last dqput() can race with dquot_scan_active() causing it to
call callback for an already deactivated dquot. The race is as follows:

    if (atomic_read(&dquot->dq_count) > 1) {
     - not taken
    if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {
        if (atomic_read(&dquot->dq_count) > 1)
         - not taken
    if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))
     - not taken
        - proceeds to release dquot
    ret = fn(dquot, priv);
     - called for inactive dquot

Fix the problem by making sure possible ->release_dquot() is finished by
the time we call the callback and new calls to it will notice reference
dquot_scan_active() has taken and bail out.

Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
7 years agoath9k: Fix ETSI compliance for AR9462 2.0
Sujith Manoharan [Fri, 14 Feb 2014 02:45:20 +0000 (08:15 +0530)]
ath9k: Fix ETSI compliance for AR9462 2.0

commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream.

The minimum CCA power threshold values have to be adjusted
for existing cards to be in compliance with new regulations.
Newer cards will make use of the values obtained from EEPROM,
support for this was added earlier. To make sure that cards
that are already in use and don't have proper values in EEPROM,
do not violate regulations, use the initvals instead.

Reported-by: Jeang Daniel <>
Signed-off-by: Sujith Manoharan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
7 years agoath9k: protect tid->sched check
Stanislaw Gruszka [Wed, 19 Feb 2014 12:15:17 +0000 (13:15 +0100)]
ath9k: protect tid->sched check

commit 21f8aaee0c62708654988ce092838aa7df4d25d8 upstream.

We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
is race condition which can result of doing list_del(&tid->list) twice
(second time with poisoned list node) and cause crash like shown below:

[424271.637220] BUG: unable to handle kernel paging request at 00100104
[424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k]
[424271.639953] Call Trace:
[424271.639998]  [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k]
[424271.640083]  [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k]
[424271.640177]  [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211]
[424271.640258]  [<c10f730e>] ? free_compound_page+0x2e/0x40
[424271.640346]  [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211]
[424271.640437]  [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0
[424271.640510]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
[424271.640578]  [<c10fc23c>] ? put_page+0x2c/0x40
[424271.640640]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
[424271.640706]  [<c1345a84>] ? kfree_skbmem+0x34/0x90
[424271.640787]  [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211]
[424271.640897]  [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211]
[424271.641009]  [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211]
[424271.641104]  [<c13846ce>] ? ip_output+0x7e/0xd0
[424271.641182]  [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211]
[424271.641266]  [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k]
[424271.641358]  [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211]
[424271.641445]  [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k]

Bug report:

Reported-and-tested-by: Max Sydorenko <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use spin_unlock_bh() directly]
Signed-off-by: Ben Hutchings <>
7 years agoSELinux: bigendian problems with filename trans rules
Eric Paris [Thu, 20 Feb 2014 15:56:45 +0000 (10:56 -0500)]
SELinux: bigendian problems with filename trans rules

commit 9085a6422900092886da8c404e1c5340c4ff1cbf upstream.

When writing policy via /sys/fs/selinux/policy I wrote the type and class
of filename trans rules in CPU endian instead of little endian.  On
x86_64 this works just fine, but it means that on big endian arch's like
ppc64 and s390 userspace reads the policy and converts it from
le32_to_cpu.  So the values are all screwed up.  Write the values in le
format like it should have been to start.

Signed-off-by: Eric Paris <>
Acked-by: Stephen Smalley <>
Signed-off-by: Paul Moore <>
Signed-off-by: Ben Hutchings <>
7 years agomac80211: fix AP powersave TX vs. wakeup race
Emmanuel Grumbach [Thu, 20 Feb 2014 07:22:11 +0000 (09:22 +0200)]
mac80211: fix AP powersave TX vs. wakeup race

commit 1d147bfa64293b2723c4fec50922168658e613ba upstream.

There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.

This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.

As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.

Additionally, it can lead to the crash below.

Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.

In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.

BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
 e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
 ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
 ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
 [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
 [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
 [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
 [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
 [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
 [<c149ef70>] dev_hard_start_xmit+0x450/0x950
 [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
 [<c14b9c9b>] __qdisc_run+0x4b/0x150
 [<c149f732>] dev_queue_xmit+0x2c2/0xca0

Reported-by: Yaara Rozenblum <>
Signed-off-by: Emmanuel Grumbach <>
Reviewed-by: Stanislaw Gruszka <>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
7 years agoASoC: wm8770: Fix wrong number of enum items
Takashi Iwai [Tue, 18 Feb 2014 08:37:30 +0000 (09:37 +0100)]
ASoC: wm8770: Fix wrong number of enum items

commit 7a6c0a58dc824523966f212c76322d47c5b0e6fe upstream.

wm8770 codec driver defines ain_enum with a wrong number of items.

Use SOC_ENUM_DOUBLE_DECL() macro and it's automatically fixed.

Signed-off-by: Takashi Iwai <>
Acked-by: Liam Girdwood <>
Acked-by: Charles Keepax <>
Acked-by: Lars-Peter Clausen <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
7 years agoACPI / video: Filter the _BCL table for duplicate brightness values
Hans de Goede [Thu, 13 Feb 2014 15:32:51 +0000 (16:32 +0100)]
ACPI / video: Filter the _BCL table for duplicate brightness values

commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.

Some devices have duplicate entries in there brightness levels table, ie
on my Dell Latitude E6430 the table looks like this:

[    3.686060] acpi backlight index   0, val 80
[    3.686095] acpi backlight index   1, val 50
[    3.686122] acpi backlight index   2, val 5
[    3.686147] acpi backlight index   3, val 5
[    3.686172] acpi backlight index   4, val 5
[    3.686197] acpi backlight index   5, val 5
[    3.686223] acpi backlight index   6, val 5
[    3.686248] acpi backlight index   7, val 5
[    3.686273] acpi backlight index   8, val 6
[    3.686332] acpi backlight index   9, val 7
[    3.686356] acpi backlight index  10, val 8
[    3.686380] acpi backlight index  11, val 9

Notice that brightness values 0-5 are all mapped to 5. This means that
if userspace writes any value between 0 and 5 to the brightness sysfs attribute
and then reads it, it will always return 0, which is somewhat unexpected.

This is a problem for ie gnome-settings-daemon, which uses read-modify-write
logic when the users presses the brightness up or down keys. This is done
this way to take brightness changes from other sources into account.

On this specific laptop what happens once the brightness has been set to 0,
is that gsd reads 0, adds 5, writes 5, and on the next brightness up key press
again reads 0, so things get stuck at the lowest brightness setting.

Filtering out the duplicate table entries, makes any write to brightness
read back as the written value as one would expect, fixing this.

Signed-off-by: Hans de Goede <>
Reviewed-by: Aaron Lu <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agoASoC: sta32x: Fix array access overflow
Takashi Iwai [Tue, 18 Feb 2014 08:24:12 +0000 (09:24 +0100)]
ASoC: sta32x: Fix array access overflow

commit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream.

Preset EQ enum of sta32x codec driver declares too many number of
items and it may lead to the access over the actual array size.

Use SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed.

Signed-off-by: Takashi Iwai <>
Acked-by: Liam Girdwood <>
Acked-by: Lars-Peter Clausen <>
Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (max1668) Fix writing the minimum temperature
Guenter Roeck [Sun, 16 Feb 2014 01:54:06 +0000 (17:54 -0800)]
hwmon: (max1668) Fix writing the minimum temperature

commit 500a91571f0a5d0d3242d83802ea2fd1faccc66e upstream.

When trying to set the minimum temperature, the driver was erroneously
writing the maximum temperature into the chip.

Signed-off-by: Guenter Roeck <>
Reviewed-by: Jean Delvare <>
Signed-off-by: Ben Hutchings <>
7 years agocgroup: update cgroup_enable_task_cg_lists() to grab siglock
Tejun Heo [Thu, 13 Feb 2014 18:29:31 +0000 (13:29 -0500)]
cgroup: update cgroup_enable_task_cg_lists() to grab siglock

commit 532de3fc72adc2a6525c4d53c07bf81e1732083d upstream.

Currently, there's nothing preventing cgroup_enable_task_cg_lists()
from missing set PF_EXITING and race against cgroup_exit().  Depending
on the timing, cgroup_exit() may finish with the task still linked on
css_set leading to list corruption.  Fix it by grabbing siglock in
cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be

This whole on-demand cg_list optimization is extremely fragile and has
ample possibility to lead to bugs which can cause things like
once-a-year oops during boot.  I'm wondering whether the better
approach would be just adding "cgroup_disable=all" handling which
disables the whole cgroup rather than tempting fate with this
on-demand craziness.

Signed-off-by: Tejun Heo <>
Acked-by: Li Zefan <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoworkqueue: ensure @task is valid across kthread_stop()
Lai Jiangshan [Sat, 15 Feb 2014 14:02:28 +0000 (22:02 +0800)]
workqueue: ensure @task is valid across kthread_stop()

commit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream.

When a kworker should die, the kworkre is notified through WORKER_DIE
flag instead of kthread_should_stop().  This, IIRC, is primarily to
keep the test synchronized inside worker_pool lock.  WORKER_DIE is
first set while holding pool->lock, the lock is dropped and
kthread_stop() is called.

Unfortunately, this means that there's a slight chance that the target
kworker may see WORKER_DIE before kthread_stop() finishes and exits
and frees the target task before or during kthread_stop().

Fix it by pinning the target task before setting WORKER_DIE and
putting it after kthread_stop() is done.

tj: Improved patch description and comment.  Moved pinning above
    WORKER_DIE for better signify what it's protecting.

Signed-off-by: Lai Jiangshan <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
Aleksander Morgado [Wed, 12 Feb 2014 15:04:45 +0000 (16:04 +0100)]
USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8

commit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream.

This interface is to be handled by the qmi_wwan driver.

CC: Hans-Christoph Schemmel <>
CC: Christian Schmiedl <>
CC: Nicolaus Colberg <>
CC: David McCullough <>
Signed-off-by: Aleksander Morgado <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: EHCI: add delay during suspend to prevent erroneous wakeups
Alan Stern [Thu, 13 Feb 2014 20:49:17 +0000 (15:49 -0500)]
USB: EHCI: add delay during suspend to prevent erroneous wakeups

commit 3e8d6d85adedc59115a564c0a54b36e42087c4d9 upstream.

High-speed USB connections revert back to full-speed signalling when
the device goes into suspend.  This takes several milliseconds, and
during that time it's not possible to tell reliably whether the device
has been disconnected.

On some platforms, the Wake-On-Disconnect circuitry gets confused
during this intermediate state.  It generates a false wakeup signal,
which can prevent the controller from going to sleep.

To avoid this problem, this patch adds a 5-ms delay to the
ehci_bus_suspend() routine if any ports have to switch over to
full-speed signalling.  (Actually, the delay was already present for
devices using a particular kind of PHY power management; the patch
merely causes the delay to be used more widely.)

Signed-off-by: Alan Stern <>
Reviewed-by: Peter Chen <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/has_tdi_phy_lpm/has_hostpc/
 - Always re-lock ehci->lock after the sleep]
Signed-off-by: Ben Hutchings <>
7 years agoahci: disable NCQ on Samsung pci-e SSDs on macbooks
Levente Kurusa [Tue, 18 Feb 2014 15:22:17 +0000 (10:22 -0500)]
ahci: disable NCQ on Samsung pci-e SSDs on macbooks

commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.

Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands.  Blacklist NCQ on the device so
that the affected machines can at least boot.

Original-patch-by: Levente Kurusa <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoARM: 7957/1: add DSB after icache flush in __flush_icache_all()
Vinayak Kale [Wed, 12 Feb 2014 06:30:01 +0000 (07:30 +0100)]
ARM: 7957/1: add DSB after icache flush in __flush_icache_all()

commit 39544ac9df20f73e49fc6b9ac19ff533388c82c0 upstream.

Add DSB after icache flush to complete the cache maintenance operation.

Signed-off-by: Vinayak Kale <>
Acked-by: Catalin Marinas <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
7 years agoavr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use
Chen Gang [Sat, 1 Feb 2014 12:35:54 +0000 (20:35 +0800)]
avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use

commit 8d80390cfc9434d5aa4fb9e5f9768a66b30cb8a6 upstream.

For avr32 cross compiler, do not define '__linux__' internally, so it
will cause issue with allmodconfig.

The related error:

    CC [M]  fs/coda/psdev.o
  In file included from include/linux/coda.h:64,
                   from fs/coda/psdev.c:45:
  include/uapi/linux/coda.h:221: error: expected specifier-qualifier-list before 'u_quad_t'

The related toolchain version (which only download, not re-compile):

  [root@gchen linux-next]# /upstream/toolchain/download/avr32-gnu-toolchain-linux_x86/bin/avr32-gcc -v
  Using built-in specs.
  Target: avr32
  Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/src/gcc/configure --target=avr32 --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-languages=c,c++ --disable-nls --disable-libssp --disable-libstdcxx-pch --with-dwarf2 --enable-version-specific-runtime-libs --disable-shared --enable-doc --with-mpfr-lib=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/lib --with-mpfr-include=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86/include --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr32-gnu-toolchain/avr32-gnu-toolchain-linux_x86 --enable-__cxa_atexit --disable-shared --with-newlib --with-pkgversion=AVR_32_bit_GNU_Toolchain_3.4.2_435 --with-bugurl=http://www
  Thread model: single
  gcc version 4.4.7 (AVR_32_bit_GNU_Toolchain_3.4.2_435)

Signed-off-by: Chen Gang <>
Acked-by: Hans-Christian Egtvedt <>
Signed-off-by: Ben Hutchings <>