5 years agom32r: add memcpy() for CONFIG_KERNEL_GZIP=y
Geert Uytterhoeven [Tue, 17 Jul 2012 22:48:04 +0000 (15:48 -0700)]
m32r: add memcpy() for CONFIG_KERNEL_GZIP=y

commit a8abbca6617e1caa2344d2d38d0a35f3e5928b79 upstream.

Fix the m32r link error:

    LD      arch/m32r/boot/compressed/vmlinux
  arch/m32r/boot/compressed/misc.o: In function `zlib_updatewindow':
  misc.c:(.text+0x190): undefined reference to `memcpy'
  misc.c:(.text+0x190): relocation truncated to fit: R_M32R_26_PLTREL against undefined symbol `memcpy'
  make[5]: *** [arch/m32r/boot/compressed/vmlinux] Error 1

by adding our own implementation of memcpy().

Signed-off-by: Geert Uytterhoeven <>
Cc: Hirokazu Takata <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Cc: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agom32r: consistently use "suffix-$(...)"
Geert Uytterhoeven [Tue, 17 Jul 2012 22:48:02 +0000 (15:48 -0700)]
m32r: consistently use "suffix-$(...)"

commit df12aef6a19bb2d69859a94936bda0e6ccaf3327 upstream.

Commit a556bec9955c ("m32r: fix arch/m32r/boot/compressed/Makefile")
changed "$(suffix_y)" to "$(suffix-y)", but didn't update any location
where "suffix_y" is set, causing:

  make[5]: *** No rule to make target `arch/m32r/boot/compressed/vmlinux.bin.', needed by `arch/m32r/boot/compressed/piggy.o'.  Stop.
  make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2
  make[3]: *** [zImage] Error 2

Correct the other locations to fix this.

Signed-off-by: Geert Uytterhoeven <>
Cc: Hirokazu Takata <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Cc: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopci: frv architecture needs generic setup-bus infrastructure
Paul Gortmaker [Wed, 18 Apr 2012 21:17:19 +0000 (17:17 -0400)]
pci: frv architecture needs generic setup-bus infrastructure

commit cd0a2bfb77a3edeecd652081e0b1a163d3b0696b upstream.

Otherwise we get this link failure for frv's defconfig:

   LD      .tmp_vmlinux1
 drivers/built-in.o: In function `pci_assign_resource':
 (.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment'
 drivers/built-in.o: In function `pci_setup':
 pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt'
 pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt'
 make[1]: *** [.tmp_vmlinux1] Error 1

Cc: David Howells <>
Acked-by: Bjorn Helgaas <>
Signed-off-by: Paul Gortmaker <>
Cc: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoPARISC: include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h
Cong Wang [Fri, 3 Feb 2012 07:34:16 +0000 (15:34 +0800)]
PARISC: include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h

commit 650275dbfb2f4c12bc91420ad5a99f955eabec98 upstream.

drivers/parisc/iommu-helpers.h:62: error: implicit declaration of function 'prefetchw'
make[3]: *** [drivers/parisc/sba_iommu.o] Error 1

drivers/parisc/iommu-helpers.h needs to #include <linux/prefetch.h>
where prefetchw is declared.

Signed-off-by: WANG Cong <>
Signed-off-by: James Bottomley <>
Cc: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotipc: fix lockdep warning during bearer initialization
Ying Xue [Thu, 16 Aug 2012 12:09:07 +0000 (12:09 +0000)]
tipc: fix lockdep warning during bearer initialization

[ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

When the lockdep validator is enabled, it will report the below
warning when we enable a TIPC bearer:

[ INFO: possible irq lock inversion dependency detected ]
Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----

  *** DEADLOCK ***

the shortest dependencies between 2nd lock and 1st lock:
  -> (ptype_lock){+.+...} ops: 10 {
                      [<c1089418>] __lock_acquire+0x528/0x13e0
                      [<c108a360>] lock_acquire+0x90/0x100
                      [<c1553c38>] _raw_spin_lock+0x38/0x50
                      [<c14651ca>] dev_add_pack+0x3a/0x60
                      [<c182da75>] arp_init+0x1a/0x48
                      [<c182dce5>] inet_init+0x181/0x27e
                      [<c1001114>] do_one_initcall+0x34/0x170
                      [<c17f7329>] kernel_init+0x110/0x1b2
                      [<c155b6a2>] kernel_thread_helper+0x6/0x10
   ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
   ... acquired at:
    [<c108a360>] lock_acquire+0x90/0x100
    [<c1553c38>] _raw_spin_lock+0x38/0x50
    [<c14651ca>] dev_add_pack+0x3a/0x60
    [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
    [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
    [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
    [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
    [<c148e802>] genl_rcv_msg+0x232/0x280
    [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
    [<c148e5bc>] genl_rcv+0x1c/0x30
    [<c148d144>] netlink_unicast+0x174/0x1f0
    [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
    [<c1456bc1>] sock_aio_write+0x161/0x170
    [<c1135a7c>] do_sync_write+0xac/0xf0
    [<c11360f6>] vfs_write+0x156/0x170
    [<c11361e2>] sys_write+0x42/0x70
    [<c155b0df>] sysenter_do_call+0x12/0x38
  -> (tipc_net_lock){+..-..} ops: 4 {
    IN-SOFTIRQ-R at:
                     [<c108953a>] __lock_acquire+0x64a/0x13e0
                     [<c108a360>] lock_acquire+0x90/0x100
                     [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                     [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                     [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                     [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                     [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                     [<c13c43d2>] pcnet32_poll+0x292/0x780
                     [<c146b00a>] net_rx_action+0xfa/0x1e0
                     [<c103a4be>] __do_softirq+0xae/0x1e0

>From the log, we can see three different call chains between
CPU0 and CPU1:

Time 0 on CPU0:


At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

Time 1 on CPU1:


At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
wants to take ptype_lock to register TIPC protocol handler into the
networking stack.  But the ptype_lock has been taken by dev_add_pack()
on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
busy looping.

Time 2 on CPU0:


At time 2, an incoming TIPC packet arrives at CPU0, hence
tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
to hold tipc_net_lock.  At the moment, below scenario happens:

On CPU0, below is our sequence of taking locks:


On CPU1, our sequence of taking locks looks like:


Obviously deadlock may happen in this case.

But please note the deadlock possibly doesn't occur at all when the
first TIPC bearer is enabled.  Before enable_bearer() -- running on
CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
recv_msg()) is not registered successfully via dev_add_pack(), so
the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
message comes to CPU0. But when the second TIPC bearer is
registered, the deadlock can perhaps really happen.

To fix it, we will push the work of registering TIPC protocol
handler into workqueue context. After the change, both paths taking
ptype_lock are always in process contexts, thus, the deadlock should
never occur.

Signed-off-by: Ying Xue <>
Signed-off-by: Jon Maloy <>
Signed-off-by: Paul Gortmaker <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO
Jiri Bohac [Fri, 30 Aug 2013 09:18:45 +0000 (11:18 +0200)]
ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

[ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
unreachable) messages:
        5 - Source address failed ingress/egress policy
6 - Reject route to destination

Now they are treated as protocol error and icmpv6_err_convert() converts them

RFC 4443 says:
"Codes 5 and 6 are more informative subsets of code 1."

Treat codes 5 and 6 as code 1 (EACCES)

Btw, connect() returning -EPROTO confuses firefox, so that fallback to
other/IPv4 addresses does not work:

Signed-off-by: Jiri Bohac <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay
Daniel Borkmann [Thu, 29 Aug 2013 21:55:05 +0000 (23:55 +0200)]
net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

[ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

While looking into MLDv1/v2 code, I noticed that bridging code does
not convert it's max delay into jiffies for MLDv2 messages as we do
in core IPv6' multicast code.

RFC3810, 5.1.3. Maximum Response Code says:

  The Maximum Response Code field specifies the maximum time allowed
  before sending a responding Report. The actual time allowed, called
  the Maximum Response Delay, is represented in units of milliseconds,
  and is derived from the Maximum Response Code as follows: [...]

As we update timers that work with jiffies, we need to convert it.

Signed-off-by: Daniel Borkmann <>
Cc: Linus Lüssing <>
Cc: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: Don't depend on per socket memory for neighbour discovery messages
Thomas Graf [Tue, 3 Sep 2013 11:37:01 +0000 (13:37 +0200)]
ipv6: Don't depend on per socket memory for neighbour discovery messages

[ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

Allocating skbs when sending out neighbour discovery messages
currently uses sock_alloc_send_skb() based on a per net namespace
socket and thus share a socket wmem buffer space.

If a netdevice is temporarily unable to transmit due to carrier
loss or for other reasons, the queued up ndisc messages will cosnume
all of the wmem space and will thus prevent from any more skbs to
be allocated even for netdevices that are able to transmit packets.

The number of neighbour discovery messages sent is very limited,
use of alloc_skb() bypasses the socket wmem buffer size enforcement
while the manual call to skb_set_owner_w() maintains the socket
reference needed for the IPv6 output path.

This patch has orginally been posted by Eric Dumazet in a modified

Signed-off-by: Thomas Graf <>
Cc: Eric Dumazet <>
Cc: Hannes Frederic Sowa <>
Cc: Stephen Warren <>
Cc: Fabio Estevam <>
Tested-by: Fabio Estevam <>
Tested-by: Stephen Warren <>
Acked-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: drop packets with multiple fragmentation headers
Hannes Frederic Sowa [Fri, 16 Aug 2013 11:30:07 +0000 (13:30 +0200)]
ipv6: drop packets with multiple fragmentation headers

[ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

It is not allowed for an ipv6 packet to contain multiple fragmentation
headers. So discard packets which were already reassembled by
fragmentation logic and send back a parameter problem icmp.

The updates for RFC 6980 will come in later, I have to do a bit more
research here.

Cc: YOSHIFUJI Hideaki <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: remove max_addresses check from ipv6_create_tempaddr
Hannes Frederic Sowa [Fri, 16 Aug 2013 11:02:27 +0000 (13:02 +0200)]
ipv6: remove max_addresses check from ipv6_create_tempaddr

[ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

Because of the max_addresses check attackers were able to disable privacy
extensions on an interface by creating enough autoconfigured addresses:


But the check is not actually needed: max_addresses protects the
kernel to install too many ipv6 addresses on an interface and guards
addrconf_prefix_rcv to install further addresses as soon as this limit
is reached. We only generate temporary addresses in direct response of
a new address showing up. As soon as we filled up the maximum number of
addresses of an interface, we stop installing more addresses and thus
also stop generating more temp addresses.

Even if the attacker tries to generate a lot of temporary addresses
by announcing a prefix and removing it again (lifetime == 0) we won't
install more temp addresses, because the temporary addresses do count
to the maximum number of addresses, thus we would stop installing new
autoconfigured addresses when the limit is reached.

This patch fixes CVE-2013-0343 (but other layer-2 attacks are still

Thanks to Ding Tianhong to bring this topic up again.

Signed-off-by: Hannes Frederic Sowa <>
Cc: Ding Tianhong <>
Cc: George Kargiotakis <>
Cc: P J P <>
Cc: YOSHIFUJI Hideaki <>
Acked-by: Ding Tianhong <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotun: signedness bug in tun_get_user()
Dan Carpenter [Thu, 15 Aug 2013 12:52:57 +0000 (15:52 +0300)]
tun: signedness bug in tun_get_user()

[ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
not totally correct.  Because "len" and "sizeof()" are size_t type, that
means they are never less than zero.

Signed-off-by: Dan Carpenter <>
Acked-by: Michael S. Tsirkin <>
Acked-by: Neil Horman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match
Hannes Frederic Sowa [Wed, 7 Aug 2013 00:34:31 +0000 (02:34 +0200)]
ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

[ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

In case a subtree did not match we currently stop backtracking and return
NULL (root table from fib_lookup). This could yield in invalid routing
table lookups when using subtrees.

Instead continue to backtrack until a valid subtree or node is found
and return this match.

Also remove unneeded NULL check.

Reported-by: Teco Boot <>
Cc: YOSHIFUJI Hideaki <>
Cc: David Lamparter <>
Cc: <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: cubic: fix bug in bictcp_acked()
Eric Dumazet [Tue, 6 Aug 2013 03:05:12 +0000 (20:05 -0700)]
tcp: cubic: fix bug in bictcp_acked()

[ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

While investigating about strange increase of retransmit rates
on hosts ~24 days after boot, Van found hystart was disabled
if ca->epoch_start was 0, as following condition is true
when tcp_time_stamp high order bit is set.

(s32)(tcp_time_stamp - ca->epoch_start) < HZ

Quoting Van :

 At initialization & after every loss ca->epoch_start is set to zero so
 I believe that the above line will turn off hystart as soon as the 2^31
 bit is set in tcp_time_stamp & hystart will stay off for 24 days.
 I think we've observed that cubic's restart is too aggressive without
 hystart so this might account for the higher drop rate we observe.

Diagnosed-by: Van Jacobson <>
Signed-off-by: Eric Dumazet <>
Cc: Neal Cardwell <>
Cc: Yuchung Cheng <>
Acked-by: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: cubic: fix overflow error in bictcp_update()
Eric Dumazet [Tue, 6 Aug 2013 00:10:15 +0000 (17:10 -0700)]
tcp: cubic: fix overflow error in bictcp_update()

[ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
overflow error in bictcp_update() in following code :

/* change the unit from HZ to bictcp_HZ */
t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
      ca->epoch_start) << BICTCP_HZ) / HZ;

Because msecs_to_jiffies() being unsigned long, compiler does
implicit type promotion.

We really want to constrain (tcp_time_stamp - ca->epoch_start)
to a signed 32bit value, or else 't' has unexpected high values.

This bugs triggers an increase of retransmit rates ~24 days after
boot [1], as the high order bit of tcp_time_stamp flips.

[1] for hosts with HZ=1000

Big thanks to Van Jacobson for spotting this problem.

Diagnosed-by: Van Jacobson <>
Signed-off-by: Eric Dumazet <>
Cc: Neal Cardwell <>
Cc: Yuchung Cheng <>
Cc: Stephen Hemminger <>
Acked-by: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofib_trie: remove potential out of bound access
Eric Dumazet [Mon, 5 Aug 2013 18:18:49 +0000 (11:18 -0700)]
fib_trie: remove potential out of bound access

[ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

AddressSanitizer [1] dynamic checker pointed a potential
out of bound access in leaf_walk_rcu()

We could allocate one more slot in tnode_new() to leave the prefetch()
in-place but it looks not worth the pain.

Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

[1] :

Reported-by: Andrey Konovalov <>
Signed-off-by: Eric Dumazet <>
Cc: Dmitry Vyukov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: check net.core.somaxconn sysctl values
Roman Gushchin [Fri, 2 Aug 2013 14:36:40 +0000 (18:36 +0400)]
net: check net.core.somaxconn sysctl values

[ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

It's possible to assign an invalid value to the net.core.somaxconn
sysctl variable, because there is no checks at all.

The sk_max_ack_backlog field of the sock structure is defined as
unsigned short. Therefore, the backlog argument in inet_listen()
shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
is truncated to the somaxconn value. So, the somaxconn value shouldn't
exceed 65535 (USHRT_MAX).
Also, negative values of somaxconn are meaningless.

$ sysctl -w net.core.somaxconn=256
net.core.somaxconn = 256
$ sysctl -w net.core.somaxconn=65536
net.core.somaxconn = 65536
$ sysctl -w net.core.somaxconn=-100
net.core.somaxconn = -100

$ sysctl -w net.core.somaxconn=256
net.core.somaxconn = 256
$ sysctl -w net.core.somaxconn=65536
error: "Invalid argument" setting key "net.core.somaxconn"
$ sysctl -w net.core.somaxconn=-100
error: "Invalid argument" setting key "net.core.somaxconn"

Based on a prior patch from Changli Gao.

Signed-off-by: Roman Gushchin <>
Reported-by: Changli Gao <>
Suggested-by: Eric Dumazet <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agohtb: fix sign extension bug
stephen hemminger [Fri, 2 Aug 2013 05:32:07 +0000 (22:32 -0700)]
htb: fix sign extension bug

[ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

When userspace passes a large priority value
the assignment of the unsigned value hopt->prio
to  signed int cl->prio causes cl->prio to become negative and the
comparison is with TC_HTB_NUMPRIO is always false.

The result is that HTB crashes by referencing outside
the array when processing packets. With this patch the large value
wraps around like other values outside the normal range.


Signed-off-by: Stephen Hemminger <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.95
Greg Kroah-Hartman [Sun, 8 Sep 2013 04:49:47 +0000 (21:49 -0700)]
Linux 3.0.95

5 years agoSCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal
Roland Dreier [Tue, 6 Aug 2013 00:55:01 +0000 (17:55 -0700)]
SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal

commit 35dc248383bbab0a7203fca4d722875bc81ef091 upstream.

There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:

 - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
   underlying SCSI command will transfer data from the SCSI device to
   the buffer provided in the ioctl)

 - Before the command finishes, a signal is sent to the process waiting
   in the ioctl.  This will end up waking up the sg_ioctl() code:

result = wait_event_interruptible(sfp->read_wait,
(srp_done(sfp, srp) || sdp->detached));

   but neither srp_done() nor sdp->detached is true, so we end up just
   setting srp->orphan and returning to userspace:

srp->orphan = 1;
return result; /* -ERESTARTSYS because signal hit process */

   At this point the original process is done with the ioctl and
   blithely goes ahead handling the signal, reissuing the ioctl, etc.

 - Eventually, the SCSI command issued by the first ioctl finishes and
   ends up in sg_rq_end_io().  At the end of that function, we run through:

write_lock_irqsave(&sfp->rq_list_lock, iflags);
if (unlikely(srp->orphan)) {
if (sfp->keep_orphan)
srp->sg_io_owned = 0;
done = 0;
srp->done = done;
write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

if (likely(done)) {
/* Now wake up any sg_read() that is waiting for this
 * packet.
kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN);
kref_put(&sfp->f_ref, sg_remove_sfp);
} else {
INIT_WORK(&srp->, sg_rq_end_io_usercontext);

   Since srp->orphan *is* set, we set done to 0 (assuming the
   userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
   ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
   to run in a workqueue.

 - In workqueue context we go through sg_rq_end_io_usercontext() ->
   sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
   bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().

   The key point here is that we are doing copy_to_user() on a
   workqueue -- that is, we're on a kernel thread with current->mm
   equal to whatever random previous user process was scheduled before
   this kernel thread.  So we end up copying whatever data the SCSI
   command returned to the virtual address of the buffer passed into
   the original ioctl, but it's quite likely we do this copying into a
   different address space!

As suggested by James Bottomley <>,
add a check for current->mm (which is NULL if we're on a kernel thread
without a real userspace address space) in bio_uncopy_user(), and skip
the copy if we're on a kernel thread.

There's no reason that I can think of for any caller of bio_uncopy_user()
to want to do copying on a kernel thread with a random active userspace
address space.

Huge thanks to Costa Sapuntzakis <> for the
original pointer to this bug in the sg code.

Signed-off-by: Roland Dreier <>
Tested-by: David Milburn <>
Cc: Jens Axboe <>
Signed-off-by: James Bottomley <>
[lizf: backported to 3.4:
 - Use __bio_for_each_segment() instead of bio_for_each_segment_all()]
Signed-off-by: Li Zefan <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotarget: Fix trailing ASCII space usage in INQUIRY vendor+model
Nicholas Bellinger [Wed, 24 Jul 2013 23:15:08 +0000 (16:15 -0700)]
target: Fix trailing ASCII space usage in INQUIRY vendor+model

commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream.

This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
spaces for INQUIRY vendor + model fields following SPC-4 text:

  "ASCII data fields described as being left-aligned shall have any
   unused bytes at the end of the field (i.e., highest offset) and
   the unused bytes shall be filled with ASCII space characters (20h)."

This addresses a problem with Falconstor NSS multipathing.

Reported-by: Tomas Molota <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
Lan Tianyu [Mon, 26 Aug 2013 02:19:18 +0000 (10:19 +0800)]
ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
Reported-and-tested-by: Daniele Esposti <>
Signed-off-by: Lan Tianyu <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoath9k_htc: Restore skb headroom when returning skb to mac80211
Helmut Schaa [Fri, 16 Aug 2013 19:39:40 +0000 (21:39 +0200)]
ath9k_htc: Restore skb headroom when returning skb to mac80211

commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 upstream.

ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.

Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.

Reported-by: Marc Kleine-Budde <>
Signed-off-by: Helmut Schaa <>
Tested-by: Marc Kleine-Budde <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/base/memory.c: fix show_mem_removable() to handle missing sections
Russ Anderson [Wed, 28 Aug 2013 23:35:18 +0000 (16:35 -0700)]
drivers/base/memory.c: fix show_mem_removable() to handle missing sections

commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream.

"cat /sys/devices/system/memory/memory*/removable" crashed the system.

The problem is that show_mem_removable() is passing a
bad pfn to is_mem_section_removable(), which causes

    if (!node_online(page_to_nid(page)))

to blow up.  Why is it passing in a bad pfn?

The reason is that show_mem_removable() will loop sections_per_block
times.  sections_per_block is 16, but mem->section_count is 8,
indicating holes in this memory block.  Checking that the memory section
is present before checking to see if the memory section is removable
fixes the problem.

   harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
   BUG: unable to handle kernel paging request at ffffea00c3200000
   IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   PGD 83ffd4067 PUD 37bdfce067 PMD 0
   Oops: 0000 [#1] SMP
   Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
   CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
   Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
   task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
   RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   RSP: 0018:ffff880820023df8  EFLAGS: 00010287
   RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
   RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
   RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
   R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
   R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
   FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
   Call Trace:

Signed-off-by: Russ Anderson <>
Cc: "Rafael J. Wysocki" <>
Cc: Yinghai Lu <>
Reviewed-by: Yasuaki Ishimatsu <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoALSA: opti9xx: Fix conflicting driver object name
Takashi Iwai [Tue, 27 Aug 2013 10:03:01 +0000 (12:03 +0200)]
ALSA: opti9xx: Fix conflicting driver object name

commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.

The recent commit to delay the release of kobject triggered NULL
dereferences of opti9xx drivers.  The cause is that all
snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
register the PnP card driver with the very same name, and also
snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
the same name, too.  When these drivers are built in, quick
"register-release-and-re-register" actions occur, and this results in
Oops because of the same name is assigned to the kobject.

The fix is simply to assign individual names.  As a bonus, by using
KBUILD_MODNAME, the patch reduces more lines than it adds.

The fix is based on the suggestion by Russell King.

Reported-and-tested-by: Fengguang Wu <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agojfs: fix readdir cookie incompatibility with NFSv4
Dave Kleikamp [Thu, 15 Aug 2013 20:36:49 +0000 (15:36 -0500)]
jfs: fix readdir cookie incompatibility with NFSv4

commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 upstream.

NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..),
but jfs allows a value of 2 for a non-special entry. This incompatibility
can result in the nfs client reporting a readdir loop.

This patch doesn't change the value stored internally, but adds one to
the value exposed to the iterate method.

Signed-off-by: Dave Kleikamp <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/ctx->pos/filp->f_pos/]
Tested-by: Christian Kujau <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.94
Greg Kroah-Hartman [Thu, 29 Aug 2013 16:43:15 +0000 (09:43 -0700)]
Linux 3.0.94

5 years agoSCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
Martin Peschke [Thu, 22 Aug 2013 15:45:37 +0000 (17:45 +0200)]
SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops

commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.

BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
CPU: 1 Not tainted 3.9.3+ #69
Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
Call Trace:
([<00000000001165de>] show_trace+0x106/0x154)
 [<00000000001166a0>] show_stack+0x74/0xf4
 [<00000000006ff646>] dump_stack+0xc6/0xd4
 [<000000000017f3a0>] __might_sleep+0x128/0x148
 [<000000000015ece8>] flush_work+0x54/0x1f8
 [<00000000001630de>] __cancel_work_timer+0xc6/0x128
 [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
 [<0000000000161816>] execute_in_process_context+0x96/0xa8
 [<00000000004d33d8>] device_release+0x60/0xc0
 [<000000000048af48>] kobject_release+0xa8/0x1c4
 [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
 [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
 [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
 [<000000000016b75a>] kthread+0xf2/0xfc
 [<000000000070c9de>] kernel_thread_starter+0x6/0xc
 [<000000000070c9d8>] kernel_thread_starter+0x0/0xc

Apparently, the ref_count for some scsi_device drops down to zero,
triggering device removal through execute_in_process_context(), while
the lldd error recovery thread iterates through a scsi device list.
Unfortunately, execute_in_process_context() decides to immediately
execute that device removal function, instead of scheduling asynchronous
execution, since it detects process context and thinks it is safe to do
so. But almost all calls to shost_for_each_device() in our lldd are
inside spin_lock_irq, even in thread context. Obviously, schedule()
inside spin_lock_irq sections is a bad idea.

Change the lldd to use the proper iterator function,
__shost_for_each_device(), in combination with required locking.

Occurences that need to be changed include all calls in zfcp_erp.c,
since those might be executed in zfcp error recovery thread context
with a lock held.

Other occurences of shost_for_each_device() in zfcp_fsf.c do not
need to be changed (no process context, no surrounding locking).

The problem was introduced in Linux 2.6.37 by commit
"[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".

Reported-by: Christian Borntraeger <>
Signed-off-by: Martin Peschke <>
Signed-off-by: Steffen Maier <>
Signed-off-by: James Bottomley <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoSCSI: zfcp: fix lock imbalance by reworking request queue locking
Martin Peschke [Thu, 22 Aug 2013 15:45:36 +0000 (17:45 +0200)]
SCSI: zfcp: fix lock imbalance by reworking request queue locking

commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.

This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
straight-forward descendant of wait_event_interruptible_timeout() and

The zfcp driver used to call wait_event_interruptible_timeout()
in combination with some intricate and error-prone locking. Using
wait_event_interruptible_lock_irq_timeout() as a replacement
nicely cleans up that locking.

This rework removes a situation that resulted in a locking imbalance
in zfcp_qdio_sbal_get():

BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
    last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]

It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194
"[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
without a required lock being held. The problem occured when a
special, non-SCSI I/O request was being submitted in process context,
when the adapter's queues had been torn down. In this case the bug
surfaced when the Fibre Channel port connection for a well-known address
was closed during a concurrent adapter shut-down procedure, which is a
rare constellation.

This patch also fixes these warnings from the sparse tool (make C=1):

drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
 'zfcp_qdio_sbal_check' - wrong count at exit
drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
 'zfcp_qdio_sbal_get' - unexpected unlock

Last but not least, we get rid of that crappy lock-unlock-lock
sequence at the beginning of the critical section.

It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.

Reported-by: Mikulas Patocka <>
Reported-by: Heiko Carstens <>
Signed-off-by: Martin Peschke <>
Signed-off-by: Steffen Maier <>
Signed-off-by: James Bottomley <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agolibata: apply behavioral quirks to sil3826 PMP
Terry Suereth [Sat, 17 Aug 2013 19:53:12 +0000 (15:53 -0400)]
libata: apply behavioral quirks to sil3826 PMP

commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.

Fixing support for the Silicon Image 3826 port multiplier, by applying
to it the same quirks applied to the Silicon Image 3726.  Specifically
fixes the repeated timeout/reset process which previously afflicted
the 3726, as described from line 290.  Slightly based on notes from:

Signed-off-by: Terry Suereth <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoHostap: copying wrong data prism2_ioctl_giwaplist()
Dan Carpenter [Fri, 9 Aug 2013 09:52:31 +0000 (12:52 +0300)]
Hostap: copying wrong data prism2_ioctl_giwaplist()

commit 909bd5926d474e275599094acad986af79671ac9 upstream.

We want the data stored in "addr" and "qual", but the extra ampersands
mean we are copying stack data instead.

Signed-off-by: Dan Carpenter <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection
Vyacheslav Dubeyko [Thu, 22 Aug 2013 23:35:45 +0000 (16:35 -0700)]
nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection

commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.

Fix the issue with improper counting number of flying bio requests for
BIO_EOPNOTSUPP error detection case.

The sb_nbio must be incremented exactly the same number of times as
complete() function was called (or will be called) because
nilfs_segbuf_wait() will call wail_for_completion() for the number of
times set to sb_nbio:

  do {
  } while (--segbuf->sb_nbio > 0);

Two functions complete() and wait_for_completion() must be called the
same number of times for the same sb_bio_event.  Otherwise,
wait_for_completion() will hang or leak.

Signed-off-by: Vyacheslav Dubeyko <>
Cc: Dan Carpenter <>
Acked-by: Ryusuke Konishi <>
Tested-by: Ryusuke Konishi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error
Vyacheslav Dubeyko [Thu, 22 Aug 2013 23:35:44 +0000 (16:35 -0700)]
nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error

commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.

Remove double call of bio_put() in nilfs_end_bio_write() for the case of
BIO_EOPNOTSUPP error detection.  The issue was found by Dan Carpenter
and he suggests first version of the fix too.

Signed-off-by: Vyacheslav Dubeyko <>
Reported-by: Dan Carpenter <>
Acked-by: Ryusuke Konishi <>
Tested-by: Ryusuke Konishi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoof: fdt: fix memory initialization for expanded DT
Wladislav Wiebe [Mon, 12 Aug 2013 11:06:53 +0000 (13:06 +0200)]
of: fdt: fix memory initialization for expanded DT

commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.

Already existing property flags are filled wrong for properties created from
initial FDT. This could cause problems if this DYNAMIC device-tree functions
are used later, i.e. properties are attached/detached/replaced. Simply dumping
flags from the running system show, that some initial static (not allocated via
kzmalloc()) nodes are marked as dynamic.

I putted some debug extensions to property_proc_show(..) :
+       if (OF_IS_DYNAMIC(pp))
+               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
+       if (OF_IS_DETACHED(pp))
+               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");

when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
will see that those flags are filled wrong, basically in most cases it will dump
a DYNAMIC or DETACHED status, which is in not true.
(BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
make a test_bit(OF_DETACHED, &x->_flags)

If nodes are dynamic kernel is allowed to kfree() them. But it will crash
attempting to do so on the nodes from FDT -- they are not allocated via

Signed-off-by: Wladislav Wiebe <>
Acked-by: Alexander Sverdlin <>
Signed-off-by: Rob Herring <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen/events: initialize local per-cpu mask for all possible events
David Vrabel [Thu, 15 Aug 2013 12:21:06 +0000 (13:21 +0100)]
xen/events: initialize local per-cpu mask for all possible events

commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.

The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
resulting in only the first 64 (or 32 in 32-bit guests) ports having
their bindings being initialized to VCPU 0.

In most cases this does not cause a problem as request_irq() will set
the irq affinity which will set the correct local per-cpu mask.
However, if the request_irq() is called on a VCPU other than 0, there
is a window between the unmasking of the event and the affinity being
set were an event may be lost because it is not locally unmasked on
any VCPU. If request_irq() is called on VCPU 0 then local irqs are
disabled during the window and the race does not occur.

Fix this by initializing all NR_EVENT_CHANNEL bits in the local
per-cpu masks.

Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agozd1201: do not use stack as URB transfer_buffer
Jussi Kivilinna [Tue, 6 Aug 2013 11:28:42 +0000 (14:28 +0300)]
zd1201: do not use stack as URB transfer_buffer

commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.

Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
to be DMA-able, which stack is not.

Patch is only compile tested.

Signed-off-by: Jussi Kivilinna <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.93
Greg Kroah-Hartman [Tue, 20 Aug 2013 17:23:58 +0000 (10:23 -0700)]
Linux 3.0.93

5 years agoRevert "genetlink: fix family dump race"
Greg Kroah-Hartman [Tue, 20 Aug 2013 17:06:19 +0000 (10:06 -0700)]
Revert "genetlink: fix family dump race"

This reverts commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1 which is
commit 58ad436fcf49810aa006016107f494c9ac9013db upstream, as there are
reported problems with it.

Cc: Johannes Berg <>
Cc: Andrei Otcheretianski <>
Cc: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.92
Greg Kroah-Hartman [Tue, 20 Aug 2013 15:21:23 +0000 (08:21 -0700)]
Linux 3.0.92

5 years agom68k: Truncate base in do_div()
Andreas Schwab [Fri, 9 Aug 2013 13:14:08 +0000 (15:14 +0200)]
m68k: Truncate base in do_div()

commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream.

Explicitly truncate the second operand of do_div() to 32 bits to guard
against bogus code calling it with a 64-bit divisor.


After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:

btrfs: setting nodatacow, compression disabled
btrfs: enabling auto recovery
btrfs: disk space caching is enabled
Current process id is 722
Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
SR: 2000  SP: 30c1fab4  a2: 30f0faf0
d0: 00000000    d1: 00001000    d2: 00000000    d3: 00000000
d4: 00010000    d5: 00000000    a0: 3085c72c    a1: 3085c72c
Process mount (pid: 722, task=30f0faf0)
Frame format=2 instr addr=319535ae
Stack from 30c1faec:
        00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
        00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
        00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
        30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
        00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
        0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000


Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68


As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()

    do_div(stripe_nr, stripe_len);

with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.

Due to the lack of truncation in the m68k-specific implementation of
do_div(), the division is performed using the upper 32-bit word of
stripe_len, which is zero.

This was introduced by commit 53b381b3abeb86f12787a6c40fee9b2f71edc23b
("Btrfs: RAID5 and RAID6"), which changed the divisor from
map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.

Reported-by: Thorsten Glaser <>
Signed-off-by: Andreas Schwab <>
Tested-by: Thorsten Glaser <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovm: add no-mmu vm_iomap_memory() stub
Linus Torvalds [Sat, 27 Apr 2013 20:25:38 +0000 (13:25 -0700)]
vm: add no-mmu vm_iomap_memory() stub

commit 3c0b9de6d37a481673e81001c57ca0e410c72346 upstream.

I think we could just move the full vm_iomap_memory() function into
util.h or similar, but I didn't get any reply from anybody actually
using nommu even to this trivial patch, so I'm not going to touch it any
more than required.

Here's the fairly minimal stub to make the nommu case at least
potentially work.  It doesn't seem like anybody cares, though.

Signed-off-by: Linus Torvalds <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoARM: 7080/1: l2x0: make sure I&D are not locked down on init
Linus Walleij [Tue, 6 Sep 2011 06:45:46 +0000 (07:45 +0100)]
ARM: 7080/1: l2x0: make sure I&D are not locked down on init

commit bac7e6ecf60933b68af910eb4c83a775a8b20b19 upstream.

Fighting unfixed U-Boots and other beasts that may the cache in
a locked-down state when starting the kernel, we make sure to
disable all cache lock-down when initializing the l2x0 so we
are in a known state.

Reviewed-by: Santosh Shilimkar <>
Reported-by: Jan Rinze <>
Cc: Srinidhi Kasagar <>
Cc: Rabin Vincent <>
Cc: Adrian Bunk <>
Cc: Rob Herring <>
Cc: Catalin Marinas <>
Cc: Will Deacon <>
Tested-by: Robert Marklund <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Russell King <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agom68k/atari: ARAnyM - Fix NatFeat module support
Geert Uytterhoeven [Thu, 25 Jul 2013 22:08:25 +0000 (00:08 +0200)]
m68k/atari: ARAnyM - Fix NatFeat module support

commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream.

As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
should be physical addresses, not virtual addresses.

Fortunately on Atari, physical and virtual kernel addresses are the same,
as long as normal kernel memory is concerned, so this usually worked fine
without conversion.

But for modules, pointers to literal strings are located in vmalloc()ed
memory. Depending on the version of ARAnyM, this causes the nf_get_id()
call to just fail, or worse, crash ARAnyM itself with e.g.

    Gotcha! Illegal memory access. Atari PC = $968c

This is a big issue for distro kernels, who want to have all drivers as
loadable modules in an initrd.

Add a wrapper for nf_get_id() that copies the literal to the stack to
work around this issue.

Reported-by: Thorsten Glaser <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopowerpc: Use -mtraceback=no
Anton Blanchard [Thu, 30 Jun 2011 13:55:27 +0000 (13:55 +0000)]
powerpc: Use -mtraceback=no

commit af9719c3062dfe216a0c3de3fa52be6d22b4456c upstream.

gcc 4.7 will be more strict about parsing the -mtraceback option:

 gcc: error: unrecognized argument in option '-mtraceback=none'
 gcc: note: valid arguments to '-mtraceback=' are: full no part

gcc used to do a 2 char compare so both "no" and "none" would
match. Switch to using -mtraceback=no should work everywhere.

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc32: Add ucmpdi2.o to obj-y instead of lib-y.
David S. Miller [Sat, 19 May 2012 22:27:01 +0000 (15:27 -0700)]
sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream.

Otherwise if no references exist in the static kernel image,
we won't export the symbol properly to modules.

Signed-off-by: David S. Miller <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosparc32: add ucmpdi2
Sam Ravnborg [Sat, 19 May 2012 09:54:11 +0000 (11:54 +0200)]
sparc32: add ucmpdi2

commit de36e66d5fa52bc6e2dacd95c701a1762b5308a7 upstream.

Based on copy from microblaze add ucmpdi2 implementation.
This fixes build of niu driver which failed with:

drivers/built-in.o: In function `niu_get_nfc':
niu.c:(.text+0x91494): undefined reference to `__ucmpdi2'

This driver will never be used on a sparc32 system,
but patch added to fix build breakage with all*config builds.

Signed-off-by: Sam Ravnborg <>
Signed-off-by: David S. Miller <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: mos7720: fix broken control requests
Johan Hovold [Tue, 13 Aug 2013 11:27:34 +0000 (13:27 +0200)]
USB: mos7720: fix broken control requests

commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream.

The parallel-port code of the drivers used a stack allocated
control-request buffer for asynchronous (and possibly deferred) control
requests. This not only violates the no-DMA-from-stack requirement but
could also lead to corrupt control requests being submitted.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agousb: add two quirky touchscreen
Oliver Neukum [Wed, 14 Aug 2013 09:01:46 +0000 (11:01 +0200)]
usb: add two quirky touchscreen

commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.

These devices tend to become unresponsive after S3

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agogenetlink: fix family dump race
Johannes Berg [Tue, 13 Aug 2013 07:04:05 +0000 (09:04 +0200)]
genetlink: fix family dump race

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.

A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.

Reported-by: Andrei Otcheretianski <>
Signed-off-by: Johannes Berg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoaf_key: initialize satype in key_notify_policy_flush()
Nicolas Dichtel [Mon, 18 Feb 2013 15:24:20 +0000 (16:24 +0100)]
af_key: initialize satype in key_notify_policy_flush()

commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

This field was left uninitialized. Some user daemons perform check against this

Signed-off-by: Nicolas Dichtel <>
Signed-off-by: Steffen Klassert <>
Cc: Luis Henriques <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoCRIS: Add _sdata to
Jesper Nilsson [Mon, 24 Oct 2011 09:19:25 +0000 (11:19 +0200)]
CRIS: Add _sdata to

commit 473e162eea465e60578edb93341752e7f1c1dacc upstream.

Fixes link error:
  LD      vmlinux
kernel/built-in.o: In function `core_kernel_data':
(.text+0x13e44): undefined reference to `_sdata'

Signed-off-by: Jesper Nilsson <>
Cc: Guenter Roeck <>
Cc: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofutex: Take hugepages into account when generating futex_key
Zhang Yi [Tue, 25 Jun 2013 13:19:31 +0000 (21:19 +0800)]
futex: Take hugepages into account when generating futex_key

commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

The futex_keys of process shared futexes are generated from the page
offset, the mapping host and the mapping index of the futex user space
address. This should result in an unique identifier for each futex.

Though this is not true when futexes are located in different subpages
of an hugepage. The reason is, that the mapping index for all those
futexes evaluates to the index of the base page of the hugetlbfs
mapping. So a futex at offset 0 of the hugepage mapping and another
one at offset PAGE_SIZE of the same hugepage mapping have identical
futex_keys. This happens because the futex code blindly uses

Steps to reproduce the bug:

1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0
   and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs

   The mutexes must be initialized as PTHREAD_PROCESS_SHARED because
   PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as
   their keys solely depend on the user space address.

2. Lock mutex1 and mutex2

3. Create thread1 and in the thread function lock mutex1, which
   results in thread1 blocking on the locked mutex1.

4. Create thread2 and in the thread function lock mutex2, which
   results in thread2 blocking on the locked mutex2.

5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2
   still blocks on mutex2 because the futex_key points to mutex1.

To solve this issue we need to take the normal page index of the page
which contains the futex into account, if the futex is in an hugetlbfs
mapping. In other words, we calculate the normal page mapping index of
the subpage in the hugetlbfs mapping.

Mappings which are not based on hugetlbfs are not affected and still
use page->index.

Thanks to Mel Gorman who provided a patch for adding proper evaluation
functions to the hugetlbfs code to avoid exposing hugetlbfs specific
details to the futex code.

[ tglx: Massaged changelog ]

Signed-off-by: Zhang Yi <>
Reviewed-by: Jiang Biao <>
Tested-by: Ma Chenggong <>
Reviewed-by: 'Mel Gorman' <>
Acked-by: 'Darren Hart' <>
Cc: 'Peter Zijlstra' <>
Signed-off-by: Thomas Gleixner <>
Cc: Mike Galbraith <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.91
Greg Kroah-Hartman [Thu, 15 Aug 2013 05:55:43 +0000 (22:55 -0700)]
Linux 3.0.91

5 years agoperf tools: Add anonymous huge page recognition
Joshua Zhu [Sat, 5 Jan 2013 05:29:57 +0000 (13:29 +0800)]
perf tools: Add anonymous huge page recognition

commit d0528b5d71faf612014dd7672e44225c915344b2 upstream.

Judging anonymous memory's vm_area_struct, perf_mmap_event's filename
will be set to "//anon" indicating this vma belongs to anonymous

Once hugepage is used, vma's vm_file points to hugetlbfs. In this way,
this vma will not be regarded as anonymous memory by is_anon_memory() in
perf user space utility.

Signed-off-by: Joshua Zhu <>
Cc: Akihiro Nagai <>
Cc: Andi Kleen <>
Cc: David Ahern <>
Cc: Ingo Molnar <>
Cc: Jiri Olsa <>
Cc: Joshua Zhu <>
Cc: Namhyung Kim <>
Cc: Paul Mackerras <>
Cc: Peter Zijlstra <>
Cc: Vinson Lee <>
Signed-off-by: Arnaldo Carvalho de Melo <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovfs: d_obtain_alias() needs to use "/" as default name.
NeilBrown [Fri, 9 Nov 2012 00:09:37 +0000 (16:09 -0800)]
vfs: d_obtain_alias() needs to use "/" as default name.

commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream.

NFS appears to use d_obtain_alias() to create the root dentry rather than
d_make_root.  This can cause 'prepend_path()' to complain that the root
has a weird name if an NFS filesystem is lazily unmounted.  e.g.  if
"/mnt" is an NFS mount then

 { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }

will cause a WARN message like
   WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
   Root dentry has weird name <>

to appear in kernel logs.

So change d_obtain_alias() to use "/" rather than "" as the anonymous

Signed-off-by: NeilBrown <>
Cc: Trond Myklebust <>
Cc: Al Viro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: use named initialisers instead of QSTR_INIT()]
Signed-off-by: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoSCSI: nsp32: use mdelay instead of large udelay constants
Arnd Bergmann [Thu, 14 Mar 2013 14:21:36 +0000 (15:21 +0100)]
SCSI: nsp32: use mdelay instead of large udelay constants

commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream.

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann <>
Acked-by: GOTO Masanori <>
Cc: YOKOTA Hiroshi <>
Cc: "James E.J. Bottomley" <>
Cc: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotracing: Fix fields of struct trace_iterator that are zeroed by mistake
Andrew Vagin [Fri, 2 Aug 2013 17:16:43 +0000 (21:16 +0400)]
tracing: Fix fields of struct trace_iterator that are zeroed by mistake

commit ed5467da0e369e65b247b99eb6403cb79172bcda upstream.

tracing_read_pipe zeros all fields bellow "seq". The declaration contains
a comment about that, but it doesn't help.

The first field is "snapshot", it's true when current open file is
snapshot. Looks obvious, that it should not be zeroed.

The second field is "started". It was converted from cpumask_t to
cpumask_var_t (v2.6.28-4983-g4462344), in other words it was
converted from cpumask to pointer on cpumask.

Currently the reference on "started" memory is lost after the first read
from tracing_read_pipe and a proper object will never be freed.

The "started" is never dereferenced for trace_pipe, because trace_pipe
can't have the TRACE_FILE_ANNOTATE options.

Signed-off-by: Andrew Vagin <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agocifs: silence compiler warnings showing up with gcc-4.7.0
Jeff Layton [Mon, 26 Mar 2012 13:55:29 +0000 (09:55 -0400)]
cifs: silence compiler warnings showing up with gcc-4.7.0

commit b2a3ad9ca502169fc4c11296fa20f56059c7c031 upstream.

gcc-4.7.0 has started throwing these warnings when building cifs.ko.

  CC [M]  fs/cifs/cifssmb.o
fs/cifs/cifssmb.c: In function ‘CIFSSMBSetCIFSACL’:
fs/cifs/cifssmb.c:3905:9: warning: array subscript is above array bounds [-Warray-bounds]
fs/cifs/cifssmb.c: In function ‘CIFSSMBSetFileInfo’:
fs/cifs/cifssmb.c:5711:8: warning: array subscript is above array bounds [-Warray-bounds]
fs/cifs/cifssmb.c: In function ‘CIFSSMBUnixSetFileInfo’:
fs/cifs/cifssmb.c:6001:25: warning: array subscript is above array bounds [-Warray-bounds]

This patch cleans up the code a bit by using the offsetof macro instead
of the funky "&pSMB->hdr.Protocol" construct.

Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodebugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
Oleg Nesterov [Fri, 26 Jul 2013 15:12:56 +0000 (17:12 +0200)]
debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)

commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.

debugfs_remove_recursive() is wrong,

1. it wrongly assumes that !list_empty(d_subdirs) means that this
   dir should be removed.

   This is not that bad by itself, but:

2. if d_subdirs does not becomes empty after __debugfs_remove()
   it gives up and silently fails, it doesn't even try to remove
   other entries.

   However ->d_subdirs can be non-empty because it still has the
   already deleted !debugfs_positive() entries.

3. simple_release_fs() is called even if __debugfs_remove() fails.

Suppose we have


and someone opens dir1/dir2/file2.

Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes

But debugfs_remove_recursive(dir1) silently fails and doesn't remove
this directory. Because it tries to delete (the already deleted)
dir1/dir2/file2 again and then fails due to "Avoid infinite loop"



cd /sys/kernel/debug/tracing
echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
sleep 1000 < events/probe/sigprocmask/id &
echo -n >| kprobe_events

[ -d events/probe ] && echo "ERR!! failed to rm probe"

And after that it is not possible to create another probe entry.

With this patch debugfs_remove_recursive() skips !debugfs_positive()
files although this is not strictly needed. The most important change
is that it does not try to make ->d_subdirs empty, it simply scans
the whole list(s) recursively and removes as much as possible.

Acked-by: Greg Kroah-Hartman <>
Signed-off-by: Oleg Nesterov <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: console: return -ENODEV on all read operations after unplug
Amit Shah [Mon, 29 Jul 2013 04:53:21 +0000 (14:23 +0930)]
virtio: console: return -ENODEV on all read operations after unplug

commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream.

If a port gets unplugged while a user is blocked on read(), -ENODEV is
returned.  However, subsequent read()s returned 0, indicating there's no
host-side connection (but not indicating the device went away).

This also happened when a port was unplugged and the user didn't have
any blocking operation pending.  If the user didn't monitor the SIGIO
signal, they won't have a chance to find out if the port went away.

Fix by returning -ENODEV on all read()s after the port gets unplugged.
write() already behaves this way.

Signed-off-by: Amit Shah <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: console: fix raising SIGIO after port unplug
Amit Shah [Mon, 29 Jul 2013 04:51:32 +0000 (14:21 +0930)]
virtio: console: fix raising SIGIO after port unplug

commit 92d3453815fbe74d539c86b60dab39ecdf01bb99 upstream.

SIGIO should be sent when a port gets unplugged.  It should only be sent
to prcesses that have the port opened, and have asked for SIGIO to be
delivered.  We were clearing out guest_connected before calling
send_sigio_to_port(), resulting in a sigio not getting sent to

Fix by setting guest_connected to false after invoking the sigio

Signed-off-by: Amit Shah <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: console: clean up port data immediately at time of unplug
Amit Shah [Mon, 29 Jul 2013 04:50:29 +0000 (14:20 +0930)]
virtio: console: clean up port data immediately at time of unplug

commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream.

We used to keep the port's char device structs and the /sys entries
around till the last reference to the port was dropped.  This is
actually unnecessary, and resulted in buggy behaviour:

1. Open port in guest
2. Hot-unplug port
3. Hot-plug a port with the same 'name' property as the unplugged one

This resulted in hot-plug being unsuccessful, as a port with the same
name already exists (even though it was unplugged).

This behaviour resulted in a warning message like this one:

WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
Hardware name: KVM
sysfs: cannot create duplicate filename

Call Trace:
 [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0
 [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50
 [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130
 [<ffffffff811f23e8>] ? create_dir+0x68/0xb0
 [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50
 [<ffffffff81273129>] ? kobject_add_internal+0xb9/0x260
 [<ffffffff812733d8>] ? kobject_add_varg+0x38/0x60
 [<ffffffff812734b4>] ? kobject_add+0x44/0x70
 [<ffffffff81349de4>] ? get_device_parent+0xf4/0x1d0
 [<ffffffff8134b389>] ? device_add+0xc9/0x650


Instead of relying on guest applications to release all references to
the ports, we should go ahead and unregister the port from all the core
layers.  Any open/read calls on the port will then just return errors,
and an unplug/plug operation on the host will succeed as expected.

This also caused buggy behaviour in case of the device removal (not just
a port): when the device was removed (which means all ports on that
device are removed automatically as well), the ports with active
users would clean up only when the last references were dropped -- and
it would be too late then to be referencing char device pointers,
resulting in oopses:

PID: 6162   TASK: ffff8801147ad500  CPU: 0   COMMAND: "cat"
 #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b
 #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322
 #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50
 #3 [ffff88011b9d5bf0] die at ffffffff8100f26b
 #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2
 #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5
    [exception RIP: strlen+2]
    RIP: ffffffff81272ae2  RSP: ffff88011b9d5d00  RFLAGS: 00010246
    RAX: 0000000000000000  RBX: ffff880118901c18  RCX: 0000000000000000
    RDX: ffff88011799982c  RSI: 00000000000000d0  RDI: 3a303030302f3030
    RBP: ffff88011b9d5d38   R8: 0000000000000006   R9: ffffffffa0134500
    R10: 0000000000001000  R11: 0000000000001000  R12: ffff880117a1cc10
    R13: 00000000000000d0  R14: 0000000000000017  R15: ffffffff81aff700
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d
 #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551
 #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb
 #9 [ffff88011b9d5de0] device_del at ffffffff813440c7


So clean up when we have all the context, and all that's left to do when
the references to the port have dropped is to free up the port struct

Reported-by: chayang <>
Reported-by: FuXiangChun <>
Reported-by: Qunfang Zhang <>
Reported-by: Sibiao Luo <>
Signed-off-by: Amit Shah <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: console: fix race in port_fops_open() and port unplug
Amit Shah [Mon, 29 Jul 2013 04:47:13 +0000 (14:17 +0930)]
virtio: console: fix race in port_fops_open() and port unplug

commit 671bdea2b9f210566610603ecbb6584c8a201c8c upstream.

Between open() being called and processed, the port can be unplugged.
Check if this happened, and bail out.

A simple test script to reproduce this is:

while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done;

This opens and closes the port a lot of times; unplugging the port while
this is happening triggers the bug.

Signed-off-by: Amit Shah <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: console: fix race with port unplug and open/close
Amit Shah [Mon, 29 Jul 2013 04:46:13 +0000 (14:16 +0930)]
virtio: console: fix race with port unplug and open/close

commit 057b82be3ca3d066478e43b162fc082930a746c9 upstream.

There's a window between find_port_by_devt() returning a port and us
taking a kref on the port, where the port could get unplugged.  Fix it
by taking the reference in find_port_by_devt() itself.

Problem reported and analyzed by Mateusz Guzik.

Reported-by: Mateusz Guzik <>
Signed-off-by: Amit Shah <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agohwmon: (adt7470) Fix incorrect return code check
Curt Brune [Thu, 8 Aug 2013 19:11:03 +0000 (12:11 -0700)]
hwmon: (adt7470) Fix incorrect return code check

commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream.

In adt7470_write_word_data(), which writes two bytes using
i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
together when they should be OR-ed together.

The return code of i2c_smbus_write_byte_data() is zero for success.

The upshot is only the first byte was ever written to the hardware.
The 2nd byte was never written out.

I noticed that trying to set the fan speed limits was not working
correctly on my system.  Setting the fan speed limits is the only
code that uses adt7470_write_word_data().  After making the change
the limit settings work and the alarms work also.

Signed-off-by: Curt Brune <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.90
Greg Kroah-Hartman [Mon, 12 Aug 2013 01:53:59 +0000 (18:53 -0700)]
Linux 3.0.90

5 years agonet_sched: info leak in atm_tc_dump_class()
Dan Carpenter [Tue, 30 Jul 2013 10:23:39 +0000 (13:23 +0300)]
net_sched: info leak in atm_tc_dump_class()

[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]

The "pvc" struct has a hole after pvc.sap_family which is not cleared.

Signed-off-by: Dan Carpenter <>
Reviewed-by: Jiri Pirko <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoaf_key: more info leaks in pfkey messages
Dan Carpenter [Sun, 28 Jul 2013 20:04:45 +0000 (23:04 +0300)]
af_key: more info leaks in pfkey messages

[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]

This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages".  There are some struct members which don't get initialized
and could disclose small amounts of private information.

Acked-by: Mathias Krause <>
Signed-off-by: Dan Carpenter <>
Acked-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet_sched: Fix stack info leak in cbq_dump_wrr().
David S. Miller [Tue, 30 Jul 2013 07:16:21 +0000 (00:16 -0700)]
net_sched: Fix stack info leak in cbq_dump_wrr().

[ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

Make sure the reserved fields, and padding (if any), are
fully initialized.

Based upon a patch by Dan Carpenter and feedback from
Joe Perches.

Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agousbnet: do not pretend to support SG/TSO
Eric Dumazet [Wed, 24 Jul 2013 00:15:54 +0000 (17:15 -0700)]
usbnet: do not pretend to support SG/TSO

[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin <>

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup
Hannes Frederic Sowa [Mon, 22 Jul 2013 21:45:53 +0000 (23:45 +0200)]
ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[<ffffffffa0366b02>]  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
 ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
 [<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6]
 [<ffffffff815bdecb>] inet_release+0xfb/0x220
 [<ffffffff815bddf2>] ? inet_release+0x22/0x220
 [<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6]
 [<ffffffff8151c1d9>] sock_release+0x29/0xa0
 [<ffffffff81525520>] sk_release_kernel+0x30/0x70
 [<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [<ffffffff8152fff9>] ops_exit_list+0x39/0x60
 [<ffffffff815306fb>] cleanup_net+0xfb/0x1a0
 [<ffffffff81075e3a>] process_one_work+0x1da/0x610
 [<ffffffff81075dc9>] ? process_one_work+0x169/0x610
 [<ffffffff81076390>] worker_thread+0x120/0x3a0
 [<ffffffff81076270>] ? process_one_work+0x610/0x610
 [<ffffffff8107da2e>] kthread+0xee/0x100
 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
 [<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0
 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP <ffff881039367bd8>
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat <>
Tested-by: Srivatsa S. Bhat <>
Signed-off-by: Hannes Frederic Sowa <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosctp: fully initialize sctp_outq in sctp_outq_init
Neil Horman [Wed, 12 Jun 2013 18:26:44 +0000 (14:26 -0400)]
sctp: fully initialize sctp_outq in sctp_outq_init

[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]

In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure.  Steve West recently asked me why I removed the q->error = 0
initalization from sctp_outq_teardown.  I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't.  sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there

Signed-off-by: Neil Horman <>
Reported-by: "West, Steve (NSN - US/Fort Worth)" <>
CC: Vlad Yasevich <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosysctl net: Keep tcp_syn_retries inside the boundary
Michal Tesar [Fri, 19 Jul 2013 12:09:01 +0000 (14:09 +0200)]
sysctl net: Keep tcp_syn_retries inside the boundary

[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the

Signed-off-by: Michal Tesar <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoarcnet: cleanup sizeof parameter
Dan Carpenter [Fri, 19 Jul 2013 05:48:05 +0000 (08:48 +0300)]
arcnet: cleanup sizeof parameter

[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoperf: Use css_tryget() to avoid propping up css refcount
Salman Qazi [Thu, 14 Jun 2012 22:31:09 +0000 (15:31 -0700)]
perf: Use css_tryget() to avoid propping up css refcount

commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

An rmdir pushes css's ref count to zero.  However, if the associated
directory is open at the time, the dentry ref count is non-zero.  If
the fd for this directory is then passed into perf_event_open, it
does a css_get().  This bounces the ref count back up from zero.  This
is a problem by itself.  But what makes it turn into a crash is the
fact that we end up doing an extra dput, since we perform a dput
when css_put sees the ref count go down to zero.

css_tryget() does not fall into that trap. So, we use that instead.

Reproduction test-case for the bug:

 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
 #include <linux/unistd.h>
 #include <linux/perf_event.h>
 #include <string.h>
 #include <errno.h>
 #include <stdio.h>

 #define PERF_FLAG_PID_CGROUP    (1U << 2)

 int perf_event_open(struct perf_event_attr *hw_event_uptr,
                     pid_t pid, int cpu, int group_fd, unsigned long flags) {
         return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                 group_fd, flags);

  * Directly poke at the perf_event bug, since it's proving hard to repro
  * depending on where in the kernel tree.  what moved?
 int main(int argc, char **argv)
        int fd;
        struct perf_event_attr attr;
        memset(&attr, 0, sizeof(attr));
        attr.exclude_kernel = 1;
        attr.size = sizeof(attr);
        mkdir("/dev/cgroup/perf_event/blah", 0777);
        fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
        perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
        return 0;

Signed-off-by: Salman Qazi <>
Signed-off-by: Peter Zijlstra <>
Acked-by: Tejun Heo <>
Signed-off-by: Ingo Molnar <>
Cc: Li Zefan <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agox86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz
H.J. Lu [Fri, 26 Jul 2013 16:11:56 +0000 (09:11 -0700)]
x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0x0000ffbf;


memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = 0x0000ffbf;

since asm statement doesn’t say it will update fx_scratch.  As the
result, the DAZ bit will be cleared.  This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoperf: Fix event group context move
Jiri Olsa [Fri, 1 Feb 2013 10:23:45 +0000 (11:23 +0100)]
perf: Fix event group context move

commit 0231bb5336758426b44ccd798ccd3c5419c95d58 upstream.

When we have group with mixed events (hw/sw) we want to end up
with group leader being in hw context. So if group leader is
initialy sw event, we move all the events under hw context.

The move is done for each event by removing it from its context
and adding it back into proper one. As a part of the removal the
event is automatically disabled, which is not what we want at
this stage of creating groups.

The fix is to initialize event state after removal from sw

This fix resulted from the following discussion:

Reported-by: Andreas Hollmann <>
Signed-off-by: Jiri Olsa <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Namhyung Kim <>
Cc: Corey Ashford <>
Cc: Frederic Weisbecker <>
Cc: Paul Mackerras <>
Cc: Peter Zijlstra <>
Cc: Stephane Eranian <>
Cc: Vince Weaver <>
Signed-off-by: Ingo Molnar <>
Cc: Li Zefan <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoMAINTAINERS: fix up stable_kernel_rules.txt location
Greg Kroah-Hartman [Mon, 5 Aug 2013 04:30:29 +0000 (12:30 +0800)]
MAINTAINERS: fix up stable_kernel_rules.txt location

There was a mismerge of 7b175c46720f8e6b92801bb634c93d1016f80c62 for the
3.0 kernel, so this fixes it up.

Also mark the stable stuff "Supported", as it is.

Reported-by: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agofanotify: info leak in copy_event_to_user()
Dan Carpenter [Mon, 8 Jul 2013 22:59:40 +0000 (15:59 -0700)]
fanotify: info leak in copy_event_to_user()

commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.

The ->reserved field isn't cleared so we leak one byte of stack
information to userspace.

Signed-off-by: Dan Carpenter <>
Cc: Eric Paris <>
Cc: Al Viro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Cc: Luis Henriques <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosched: Fix the broken sched_rr_get_interval()
Zhu Yanhai [Tue, 8 Jan 2013 04:56:52 +0000 (12:56 +0800)]
sched: Fix the broken sched_rr_get_interval()

commit a59f4e079d19464eebb9b06513a1d4f55fdae5ba upstream.

The caller of sched_sliced() should pass se.cfs_rq and se as the
arguments, however in sched_rr_get_interval() we gave it
rq.cfs_rq and se, which made the following computation obviously

The change was introduced by commit:

  77034937dc45 sched: fix crash in sys_sched_rr_get_interval()

... 5 years ago, while it had been the correct 'cfs_rq_of' before
the commit. The change seems to be irrelevant to the commit
msg, which was to return a 0 timeslice for tasks that are on an
idle runqueue. So I believe that was just a plain typo.

Signed-off-by: Zhu Yanhai <>
Cc: Peter Zijlstra <>
Cc: Paul Turner <>
Cc: Thomas Gleixner <>
Cc: Steven Rostedt <>
Cc: Andrew Morton <>
Cc: Linus Torvalds <>
[ Since this is an ABI and an old bug, we'll test this via a
  slow upstream route, to hopefully discover any app breakage. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoACPI / battery: Fix parsing _BIX return value
Lan Tianyu [Tue, 30 Jul 2013 12:00:42 +0000 (14:00 +0200)]
ACPI / battery: Fix parsing _BIX return value

commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section, the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann <>
Signed-off-by: Lan Tianyu <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomwifiex: Add missing endian conversion.
Tomasz Moń [Tue, 23 Jul 2013 05:42:49 +0000 (07:42 +0200)]
mwifiex: Add missing endian conversion.

commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń <>
Acked-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agort2x00: fix stop queue
Stanislaw Gruszka [Sun, 28 Jul 2013 11:17:22 +0000 (13:17 +0200)]
rt2x00: fix stop queue

commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomac80211: fix duplicate retransmission detection
Johannes Berg [Thu, 11 Jul 2013 20:33:26 +0000 (22:33 +0200)]
mac80211: fix duplicate retransmission detection

commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Signed-off-by: Johannes Berg <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonl80211: fix mgmt tx status and testmode reporting for netns
Michal Kazior [Tue, 25 Jun 2013 07:17:17 +0000 (09:17 +0200)]
nl80211: fix mgmt tx status and testmode reporting for netns

commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

These two events were sent to the default network

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Signed-off-by: Michal Kazior <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoath9k_htc: do some initial hardware configuration
Oleksij Rempel [Fri, 19 Jul 2013 18:16:17 +0000 (20:16 +0200)]
ath9k_htc: do some initial hardware configuration

commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Tested-by: Bo Shi <>
Signed-off-by: Oleksij Rempel <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoserial/mxs-auart: increase time to wait for transmitter to become idle
Uwe Kleine-König [Fri, 28 Jun 2013 09:49:41 +0000 (11:49 +0200)]
serial/mxs-auart: increase time to wait for transmitter to become idle

commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.

Without this patch the driver waits ~1 ms for the UART to become idle. At
115200n8 this time is (theoretically) enough to transfer 11.5 characters
(= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
of 16 characters the clock is gated too early. The problem is worse for
lower baud rates.

This only happens to really shut down the transmitter in the middle of a
transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
was at least once (because the bootloader doesn't disable the transmitter).

So increase the timeout to 20 ms which should be enough for 9600n8, too.
Moreover skip gating the clock if the timeout is elapsed.

Signed-off-by: Uwe Kleine-König <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoserial/mxs-auart: fix race condition in interrupt handler
Uwe Kleine-König [Thu, 4 Jul 2013 09:28:51 +0000 (11:28 +0200)]
serial/mxs-auart: fix race condition in interrupt handler

commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.

The handler needs to ack the pending events before actually handling them.
Otherwise a new event might come in after it it considered non-pending or
handled and is acked then without being handled. So this event is only
noticed when the next interrupt happens.

Without this patch an i.MX28 based machine running an rt-patched kernel
regularly hangs during boot.

Signed-off-by: Uwe Kleine-König <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.0.89
Greg Kroah-Hartman [Sun, 4 Aug 2013 07:45:13 +0000 (15:45 +0800)]
Linux 3.0.89

5 years agoUSB: storage: Add MicroVault Flash Drive to unusual_devs
Ren Bigcren [Tue, 2 Jul 2013 11:34:30 +0000 (13:34 +0200)]
USB: storage: Add MicroVault Flash Drive to unusual_devs

commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.

The device report an error capacity when read_capacity_16().
Using read_capacity_10() can get the correct capacity.

Signed-off-by: Ren Bigcren <>
Cc: Matthew Dharm <>
Signed-off-by: Oskar Andero <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomm/memory-hotplug: fix lowmem count overflow when offline pages
Wanpeng Li [Wed, 3 Jul 2013 22:02:40 +0000 (15:02 -0700)]
mm/memory-hotplug: fix lowmem count overflow when offline pages

commit cea27eb2a202959783f81254c48c250ddd80e129 upstream.

The logic for the memory-remove code fails to correctly account the
Total High Memory when a memory block which contains High Memory is
offlined as shown in the example below.  The following patch fixes it.

Before logic memory remove:

MemTotal:        7603740 kB
MemFree:         6329612 kB
Buffers:           94352 kB
Cached:           872008 kB
SwapCached:            0 kB
Active:           626932 kB
Inactive:         519216 kB
Active(anon):     180776 kB
Inactive(anon):   222944 kB
Active(file):     446156 kB
Inactive(file):   296272 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       7294672 kB
HighFree:        5704696 kB
LowTotal:         309068 kB
LowFree:          624916 kB

After logic memory remove:

MemTotal:        7079452 kB
MemFree:         5805976 kB
Buffers:           94372 kB
Cached:           872000 kB
SwapCached:            0 kB
Active:           626936 kB
Inactive:         519236 kB
Active(anon):     180780 kB
Inactive(anon):   222944 kB
Active(file):     446156 kB
Inactive(file):   296292 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:       7294672 kB
HighFree:        5181024 kB
LowTotal:       4294752076 kB
LowFree:          624952 kB

[ fix CONFIG_HIGHMEM=n build]
Signed-off-by: Wanpeng Li <>
Reviewed-by: Michal Hocko <>
Cc: KAMEZAWA Hiroyuki <>
Cc: David Rientjes <>
Cc: <> [2.6.24+]
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Zhouping Liu <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio_net: fix race in RX VQ processing
Michael S. Tsirkin [Sun, 4 Aug 2013 07:43:40 +0000 (15:43 +0800)]
virtio_net: fix race in RX VQ processing

commit cbdadbbf0c790f79350a8f36029208944c5487d0 upstream

virtio net called virtqueue_enable_cq on RX path after napi_complete, so
with NAPI_STATE_SCHED clear - outside the implicit napi lock.
This violates the requirement to synchronize virtqueue_enable_cq wrt
virtqueue_add_buf.  In particular, used event can move backwards,
causing us to lose interrupts.
In a debug build, this can trigger panic within START_USE.

Jason Wang reports that he can trigger the races artificially,
by adding udelay() in virtqueue_enable_cb() after virtio_mb().

However, we must call napi_complete to clear NAPI_STATE_SCHED before
polling the virtqueue for used buffers, otherwise napi_schedule_prep in
a callback will fail, causing us to lose RX events.

To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
set (under napi lock), later call virtqueue_poll with
NAPI_STATE_SCHED clear (outside the lock).

Reported-by: Jason Wang <>
Tested-by: Jason Wang <>
Acked-by: Jason Wang <>
Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
[wg: Backported to 3.2]
Signed-off-by: Wolfram Gloger <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio: support unlocked queue poll
Michael S. Tsirkin [Sun, 4 Aug 2013 07:43:40 +0000 (15:43 +0800)]
virtio: support unlocked queue poll

commit cc229884d3f77ec3b1240e467e0236c3e0647c0c upstream.

This adds a way to check ring empty state after enable_cb outside any
locks. Will be used by virtio_net.

Note: there's room for more optimization: caller is likely to have a
memory barrier already, which means we might be able to get rid of a
barrier here.  Deferring this optimization until we do some

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
[wg: Backported to 3.2]
Signed-off-by: Wolfram Gloger <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen/evtchn: avoid a deadlock when unbinding an event channel
David Vrabel [Fri, 19 Jul 2013 14:51:58 +0000 (15:51 +0100)]
xen/evtchn: avoid a deadlock when unbinding an event channel

commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream.

Unbinding an event channel (either with the ioctl or when the evtchn
device is closed) may deadlock because disable_irq() is called with
port_user_lock held which is also locked by the interrupt handler.

Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
just taken the lock, and an interrupt happens. The evtchn_interrupt
is invoked, tries to take the lock and spins forever.

A quick glance at the code shows that the spinlock is a local IRQ
variant. Unfortunately that does not help as "disable_irq() waits for
the interrupt handler on all CPUs to stop running.  If the irq occurs
on another VCPU, it tries to take port_user_lock and can't because
the unbind ioctl is holding it." (from David). Hence we cannot
depend on the said spinlock to protect us. We could make it a system
wide IRQ disable spinlock but there is a better way.

We can piggyback on the fact that the existence of the spinlock is
to make get_port_user() checks be up-to-date. And we can alter those
checks to not depend on the spin lock (as it's protected by u->bind_mutex
in the ioctl) and can remove the unnecessary locking (this is

In the interrupt handler we cannot use the mutex, but we do not
need it.

"The unbind disables the irq before making the port user stale, so when
you clear it you are guaranteed that the interrupt handler that might
use that port cannot be running." (from David).

Hence this patch removes the spinlock usage on the teardown path
and piggybacks on disable_irq happening before we muck with the
get_port_user() data. This ensures that the interrupt handler will
never run on stale data.

Signed-off-by: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
[v1: Expanded the commit description a bit]
Signed-off-by: Jonghwan Choi <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agolivelock avoidance in sget()
Al Viro [Fri, 19 Jul 2013 23:13:55 +0000 (03:13 +0400)]
livelock avoidance in sget()

commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream.

Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
to fail.  The superblock is on ->fs_supers, ->s_umount is held exclusive,
->s_active is 1.  Along comes two more processes, trying to mount the same
thing; sget() in each is picking that superblock, bumping ->s_count and
trying to grab ->s_umount.  ->s_active is 3 now.  Original mount(2)
finally gets to deactivate_locked_super() on failure; ->s_active is 2,
superblock is still ->fs_supers because shutdown will *not* happen until
->s_active hits 0.  ->s_umount is dropped and now we have two processes
chasing each other:
s_active = 2, A acquired ->s_umount, B blocked
A sees that the damn thing is stillborn, does deactivate_locked_super()
s_active = 1, A drops ->s_umount, B gets it
A restarts the search and finds the same superblock.  And bumps it ->s_active.
s_active = 2, B holds ->s_umount, A blocked on trying to get it
... and we are in the earlier situation with A and B switched places.

The root cause, of course, is that ->s_active should not grow until we'd
got MS_BORN.  Then failing ->mount() will have deactivate_locked_super()
shut the damn thing down.  Fortunately, it's easy to do - the key point
is that grab_super() is called only for superblocks currently on ->fs_supers,
so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
bump ->s_active; we must never increment ->s_count for superblocks past
->kill_sb(), but grab_super() is never called for those.

The bug is pretty old; we would've caught it by now, if not for accidental
exclusion between sget() for block filesystems; the things like cgroup or
e.g. mtd-based filesystems don't have anything of that sort, so they get
bitten.  The right way to deal with that is obviously to fix sget()...

Signed-off-by: Al Viro <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: serial: ftdi_sio: add more RT Systems ftdi devices
Rick Farina (Zero_Chaos) [Mon, 29 Jul 2013 19:17:59 +0000 (15:17 -0400)]
USB: serial: ftdi_sio: add more RT Systems ftdi devices

commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.

RT Systems makes many usb serial cables based on the ftdi_sio driver for
programming various amateur radios.  This patch is a full listing of
their current product offerings and should allow these cables to all
be recognized.

Signed-off-by: Rick Farina (Zero_Chaos) <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon/atom: initialize more atom interpretor elements to 0
Alex Deucher [Tue, 30 Jul 2013 04:22:53 +0000 (00:22 -0400)]
drm/radeon/atom: initialize more atom interpretor elements to 0

commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.


Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: improve dac adjust heuristics for legacy pdac
Alex Deucher [Fri, 19 Jul 2013 21:44:43 +0000 (17:44 -0400)]
drm/radeon: improve dac adjust heuristics for legacy pdac

commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.

Hopefully avoid more quirks in the future due to bogus
vbios dac data.

Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: fix combios tables on older cards
Mark Kettenis [Sun, 21 Jul 2013 20:44:09 +0000 (16:44 -0400)]
drm/radeon: fix combios tables on older cards

commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.

Noticed that my old Radeon 7500 hung after printing

   drm: GPU not posted. posting now...

when it wasn't selected as the primary card the BIOS.  Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage.  No surprise it hangs!

Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
table is found through the MISC INFO table.  The MISC INFO table can
be found at offset 0x5e in the COMBIOS header.  But the header is
smaller than that.  The COMBIOS header starts at offset 0x126.  The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180.  That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.

I looked at a dozen or so BIOS images, some my own, some downloaded from:


It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header.  Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.

So I think combios_get_table_offset() should check if the requested
table is present.  This can be done by checking the offset against the
size of the header.  See the diff below.  The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point.  But I don't think this bit of the code changed much since

For what it is worth:

Signed-off-by: Mark Kettenis <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoACPI / memhotplug: Fix a stale pointer in error path
Toshi Kani [Wed, 10 Jul 2013 16:47:13 +0000 (10:47 -0600)]
ACPI / memhotplug: Fix a stale pointer in error path

commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.

device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.

Signed-off-by: Toshi Kani <>
Reviewed-by: Yasuaki Ishimatsu <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopowerpc/modules: Module CRC relocation fix causes perf issues
Anton Blanchard [Mon, 15 Jul 2013 04:04:50 +0000 (14:04 +1000)]
powerpc/modules: Module CRC relocation fix causes perf issues

commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.

Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.

Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:

# head -2 /proc/kallsyms
0000000000000000 T reloc_start
c000000000000000 T .__start

This reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000000000000000 and we get various cryptic errors out of perf,

problem incrementing symbol count, skipping event

This patch removes the  reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.

Signed-off-by: Anton Blanchard <>
Acked-by: Rusty Russell <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>