5 years agox86: Do not leak kernel page mapping locations
Kees Cook [Thu, 7 Feb 2013 17:44:13 +0000 (09:44 -0800)]
x86: Do not leak kernel page mapping locations

commit e575a86fdc50d013bf3ad3aa81d9100e8e6cc60d upstream.

Without this patch, it is trivial to determine kernel page
mappings by examining the error code reported to dmesg[1].
Instead, declare the entire kernel memory space as a violation
of a present page.

Additionally, since show_unhandled_signals is enabled by
default, switch branch hinting to the more realistic
expectation, and unobfuscate the setting of the PF_PROT bit to
improve readability.


Reported-by: Dan Rosenberg <>
Suggested-by: Brad Spengler <>
Signed-off-by: Kees Cook <>
Acked-by: H. Peter Anvin <>
Cc: Paul E. McKenney <>
Cc: Frederic Weisbecker <>
Cc: Eric W. Biederman <>
Cc: Linus Torvalds <>
Cc: Andrew Morton <>
Cc: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agos390/timer: avoid overflow when programming clock comparator
Heiko Carstens [Tue, 29 Jan 2013 08:16:28 +0000 (09:16 +0100)]
s390/timer: avoid overflow when programming clock comparator

commit d911e03d097bdc01363df5d81c43f69432eb785c upstream.

Since ed4f209 "s390/time: fix sched_clock() overflow" a new helper function
is used to avoid overflows when converting TOD format values to nanosecond
The kvm interrupt code formerly however only worked by accident because of
an overflow. It tried to program a timer that would expire in more than ~29
years. Because of the old TOD-to-nanoseconds overflow bug the real expiry
value however was much smaller, but now it isn't anymore.
This however triggers yet another bug in the function that programs the clock
comparator s390_next_ktime(): if the absolute "expires" value is after 2042
this will result in an overflow and the programmed value is lower than the
current TOD value which immediatly triggers a clock comparator (= timer)
Since the timer isn't expired it will be programmed immediately again and so
on... the result is a dead system.
To fix this simply program the maximum possible value if an overflow is

Reported-by: Christian Borntraeger <>
Tested-by: Christian Borntraeger <>
Signed-off-by: Heiko Carstens <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomm: don't overwrite mm->def_flags in do_mlockall()
Gerald Schaefer [Tue, 12 Feb 2013 21:46:20 +0000 (13:46 -0800)]
mm: don't overwrite mm->def_flags in do_mlockall()

commit 9977f0f164d46613288e0b5778eae500dfe06f31 upstream.

With commit 8e72033f2a48 ("thp: make MADV_HUGEPAGE check for
mm->def_flags") the VM_NOHUGEPAGE flag may be set on s390 in
mm->def_flags for certain processes, to prevent future thp mappings.
This would be overwritten by do_mlockall(), which sets it back to 0 with
an optional VM_LOCKED flag set.

To fix this, instead of overwriting mm->def_flags in do_mlockall(), only
the VM_LOCKED flag should be set or cleared.

Signed-off-by: Gerald Schaefer <>
Reported-by: Vivek Goyal <>
Cc: Andrea Arcangeli <>
Cc: Hugh Dickins <>
Cc: Martin Schwidefsky <>
Cc: Heiko Carstens <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/rtc/rtc-pl031.c: restore ST variant functionality
Linus Walleij [Tue, 12 Feb 2013 21:46:19 +0000 (13:46 -0800)]
drivers/rtc/rtc-pl031.c: restore ST variant functionality

commit 3399cfb5df9594495b876d1843a7165f77366b2b upstream.

Commit e7e034e18a0a ("drivers/rtc/rtc-pl031.c: fix the missing operation
on enable") accidentally broke the ST variants of PL031.

The bit that is being poked as "clockwatch" enable bit for the ST
variants does the work of bit 0 on this variant.  Bit 0 is used for a
clock divider on the ST variants, and setting it to 1 will affect
timekeeping in a very bad way.

Signed-off-by: Linus Walleij <>
Acked-by: Haojian Zhuang <>
Cc: Mian Yousaf KAUKAB <>
Cc: Srinidhi Kasagar <>
Cc: Alessandro Zummo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoRevert: xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
Greg Kroah-Hartman [Thu, 14 Feb 2013 19:22:53 +0000 (11:22 -0800)]
Revert: xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end

This reverts commit a56040731e5b00081c6d6c26b99e6e257a5d63d7 which was
commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.

It has been reported to cause problems:

Acked-by: Ben Myers <>
Acked-by: Dave Chinner <>
Cc: Brian Foster <>
Cc: CAI Qian <>
Cc: Paolo Bonzini <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.7.8
Greg Kroah-Hartman [Thu, 14 Feb 2013 18:57:59 +0000 (10:57 -0800)]
Linux 3.7.8

5 years agodrm/nouveau: add lockdep annotations
Marcin Slusarz [Mon, 4 Feb 2013 20:52:54 +0000 (21:52 +0100)]
drm/nouveau: add lockdep annotations

commit 5f97ab913cf0fbc378ea8ffc3ee66f4890d11c55 upstream.

1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
2) DRM client can be locked under user client lock - tell lockdep to put
DRM client lock in a separate class.

Reported-by: Arend van Spriel <>
Reported-by: Peter Hurley <>
Reported-by: Maarten Lankhorst <>
Reported-by: Daniel J Blueman <>
Signed-off-by: Marcin Slusarz <>
Signed-off-by: Ben Skeggs <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: splice: fix __splice_segment()
Eric Dumazet [Fri, 11 Jan 2013 14:46:37 +0000 (14:46 +0000)]
net: splice: fix __splice_segment()

[ Upstream commit bc9540c637c3d8712ccbf9dcf28621f380ed5e64 ]

commit 9ca1b22d6d2 (net: splice: avoid high order page splitting)
forgot that skb->head could need a copy into several page frags.

This could be the case for loopback traffic mostly.

Also remove now useless skb argument from linear_to_page()
and __splice_segment() prototypes.

Signed-off-by: Eric Dumazet <>
Cc: Willy Tarreau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: splice: avoid high order page splitting
Eric Dumazet [Sat, 5 Jan 2013 21:31:18 +0000 (21:31 +0000)]
net: splice: avoid high order page splitting

[ Upstream commit 82bda6195615891181115f579a480aa5001ce7e9 ]

splice() can handle pages of any order, but network code tries hard to
split them in PAGE_SIZE units. Not quite successfully anyway, as
__splice_segment() assumed poff < PAGE_SIZE. This is true for
the skb->data part, not necessarily for the fragments.

This patch removes this logic to give the pages as they are in the skb.

Signed-off-by: Eric Dumazet <>
Cc: Willy Tarreau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: fix splice() and tcp collapsing interaction
Eric Dumazet [Wed, 9 Jan 2013 20:59:09 +0000 (20:59 +0000)]
tcp: fix splice() and tcp collapsing interaction

[ Upstream commit f26845b43c75d3f32f98d194c1327b5b1e6b3fb0 ]

Under unusual circumstances, TCP collapse can split a big GRO TCP packet
while its being used in a splice(socket->pipe) operation.

skb_splice_bits() releases the socket lock before calling

[ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
[ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
[ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13

To fix this problem, we must eat skbs in tcp_recv_skb().

Remove the inline keyword from tcp_recv_skb() definition since
it has three call sites.

Reported-by: Christian Becker <>
Cc: Willy Tarreau <>
Signed-off-by: Eric Dumazet <>
Tested-by: Willy Tarreau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: splice: fix an infinite loop in tcp_read_sock()
Eric Dumazet [Thu, 10 Jan 2013 07:06:10 +0000 (07:06 +0000)]
tcp: splice: fix an infinite loop in tcp_read_sock()

[ Upstream commit ff905b1e4aad8ccbbb0d42f7137f19482742ff07 ]

commit 02275a2ee7c0 (tcp: don't abort splice() after small transfers)
added a regression.

[   83.843570] INFO: rcu_sched self-detected stall on CPU
[   83.844575] INFO: rcu_sched detected stalls on CPUs/tasks: { 6} (detected by 0, t=21002 jiffies, g=4457, c=4456, q=13132)
[   83.844582] Task dump for CPU 6:
[   83.844584] netperf         R  running task        0  8966   8952 0x0000000c
[   83.844587]  0000000000000000 0000000000000006 0000000000006c6c 0000000000000000
[   83.844589]  000000000000006c 0000000000000096 ffffffff819ce2bc ffffffffffffff10
[   83.844592]  ffffffff81088679 0000000000000010 0000000000000246 ffff880c4b9ddcd8
[   83.844594] Call Trace:
[   83.844596]  [<ffffffff81088679>] ? vprintk_emit+0x1c9/0x4c0
[   83.844601]  [<ffffffff815ad449>] ? schedule+0x29/0x70
[   83.844606]  [<ffffffff81537bd2>] ? tcp_splice_data_recv+0x42/0x50
[   83.844610]  [<ffffffff8153beaa>] ? tcp_read_sock+0xda/0x260
[   83.844613]  [<ffffffff81537b90>] ? tcp_prequeue_process+0xb0/0xb0
[   83.844615]  [<ffffffff8153c0f0>] ? tcp_splice_read+0xc0/0x250
[   83.844618]  [<ffffffff814dc0c2>] ? sock_splice_read+0x22/0x30
[   83.844622]  [<ffffffff811b820b>] ? do_splice_to+0x7b/0xa0
[   83.844627]  [<ffffffff811ba4bc>] ? sys_splice+0x59c/0x5d0
[   83.844630]  [<ffffffff8119745b>] ? putname+0x2b/0x40
[   83.844633]  [<ffffffff8118bcb4>] ? do_sys_open+0x174/0x1e0
[   83.844636]  [<ffffffff815b6202>] ? system_call_fastpath+0x16/0x1b

if recv_actor() returns 0, we should stop immediately,
because looping wont give a chance to drain the pipe.

Signed-off-by: Eric Dumazet <>
Cc: Willy Tarreau <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: don't abort splice() after small transfers
Willy Tarreau [Sun, 2 Dec 2012 11:49:27 +0000 (11:49 +0000)]
tcp: don't abort splice() after small transfers

[ Upstream commit 02275a2ee7c0ea475b6f4a6428f5df592bc9d30b ]

TCP coalescing added a regression in splice(socket->pipe) performance,
for some workloads because of the way tcp_read_sock() is implemented.

The reason for this is the break when (offset + 1 != skb->len).

As we released the socket lock, this condition is possible if TCP stack
added a fragment to the skb, which can happen with TCP coalescing.

So let's go back to the beginning of the loop when this happens,
to give a chance to splice more frags per system call.

Doing so fixes the issue and makes GRO 10% faster than LRO
on CPU-bound splice() workloads instead of the opposite.

Signed-off-by: Willy Tarreau <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: fix for zero packets_in_flight was too broad
Ilpo Järvinen [Mon, 4 Feb 2013 02:14:25 +0000 (02:14 +0000)]
tcp: fix for zero packets_in_flight was too broad

[ Upstream commit 6731d2095bd4aef18027c72ef845ab1087c3ba63 ]

There are transients during normal FRTO procedure during which
the packets_in_flight can go to zero between write_queue state
updates and firing the resulting segments out. As FRTO processing
occurs during that window the check must be more precise to
not match "spuriously" :-). More specificly, e.g., when
packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic
branch that set cwnd into zero would not be taken and new segments
might be sent out later.

Signed-off-by: Ilpo Järvinen <>
Tested-by: Eric Dumazet <>
Acked-by: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: frto should not set snd_cwnd to 0
Eric Dumazet [Sun, 3 Feb 2013 09:13:05 +0000 (09:13 +0000)]
tcp: frto should not set snd_cwnd to 0

[ Upstream commit 2e5f421211ff76c17130b4597bc06df4eeead24f ]

Commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start())
uncovered a bug in FRTO code :
tcp_process_frto() is setting snd_cwnd to 0 if the number
of in flight packets is 0.

As Neal pointed out, if no packet is in flight we lost our
chance to disambiguate whether a loss timeout was spurious.

We should assume it was a proper loss.

Reported-by: Pasi Kärkkäinen <>
Signed-off-by: Neal Cardwell <>
Signed-off-by: Eric Dumazet <>
Cc: Ilpo Järvinen <>
Cc: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: fix an infinite loop in tcp_slow_start()
Eric Dumazet [Sat, 2 Feb 2013 05:23:16 +0000 (05:23 +0000)]
tcp: fix an infinite loop in tcp_slow_start()

[ Upstream commit 973ec449bb4f2b8c514bacbcb4d9506fc31c8ce3 ]

Since commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start()),
a nul snd_cwnd triggers an infinite loop in tcp_slow_start()

Avoid this infinite loop and log a one time error for further
analysis. FRTO code is suspected to cause this bug.

Reported-by: Pasi Kärkkäinen <>
Signed-off-by: Eric Dumazet <>
Cc: Neal Cardwell <>
Cc: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: detect SYN/data drop when F-RTO is disabled
Yuchung Cheng [Thu, 31 Jan 2013 19:16:46 +0000 (11:16 -0800)]
tcp: detect SYN/data drop when F-RTO is disabled

[ Upstream commit 66555e92fb7a619188c02cceae4bbc414f15f96d ]

On receiving the SYN-ACK, Fast Open checks icsk_retransmit for SYN
retransmission to detect SYN/data drops. But if F-RTO is disabled,
icsk_retransmit is reset at step D of tcp_fastretrans_alert() (
under tcp_ack()) before tcp_rcv_fastopen_synack(). The fix is to use
total_retrans instead which accounts for SYN retransmission regardless
the use of F-RTO.

Signed-off-by: Yuchung Cheng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: sctp: sctp_endpoint_free: zero out secret key data
Daniel Borkmann [Fri, 8 Feb 2013 03:04:35 +0000 (03:04 +0000)]
net: sctp: sctp_endpoint_free: zero out secret key data

[ Upstream commit b5c37fe6e24eec194bb29d22fdd55d73bcc709bf ]

On sctp_endpoint_destroy, previously used sensitive keying material
should be zeroed out before the memory is returned, as we already do
with e.g. auth keys when released.

Signed-off-by: Daniel Borkmann <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: sctp: sctp_setsockopt_auth_key: use kzfree instead of kfree
Daniel Borkmann [Fri, 8 Feb 2013 03:04:34 +0000 (03:04 +0000)]
net: sctp: sctp_setsockopt_auth_key: use kzfree instead of kfree

[ Upstream commit 6ba542a291a5e558603ac51cda9bded347ce7627 ]

In sctp_setsockopt_auth_key, we create a temporary copy of the user
passed shared auth key for the endpoint or association and after
internal setup, we free it right away. Since it's sensitive data, we
should zero out the key before returning the memory back to the
allocator. Thus, use kzfree instead of kfree, just as we do in

Signed-off-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosctp: refactor sctp_outq_teardown to insure proper re-initalization
Neil Horman [Thu, 17 Jan 2013 11:15:08 +0000 (11:15 +0000)]
sctp: refactor sctp_outq_teardown to insure proper re-initalization

[ Upstream commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86 ]

Jamie Parsons reported a problem recently, in which the re-initalization of an
association (The duplicate init case), resulted in a loss of receive window
space.  He tracked down the root cause to sctp_outq_teardown, which discarded
all the data on an outq during a re-initalization of the corresponding
association, but never reset the outq->outstanding_data field to zero.  I wrote,
and he tested this fix, which does a proper full re-initalization of the outq,
fixing this problem, and hopefully future proofing us from simmilar issues down
the road.

Signed-off-by: Neil Horman <>
Reported-by: Jamie Parsons <>
Tested-by: Jamie Parsons <>
CC: Jamie Parsons <>
CC: Vlad Yasevich <>
CC: "David S. Miller" <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: Fix route refcount on pmtu discovery
Steffen Klassert [Tue, 22 Jan 2013 00:01:28 +0000 (00:01 +0000)]
ipv4: Fix route refcount on pmtu discovery

[ Upstream commit b44108dbdbaa07c609bb5755e8dd6c2035236251 ]

git commit 9cb3a50c (ipv4: Invalidate the socket cached route on
pmtu events if possible) introduced a refcount problem. We don't
get a refcount on the route if we get it from__sk_dst_get(), but
we need one if we want to reuse this route because __sk_dst_set()
releases the refcount of the old route. This patch adds proper
refcount handling for that case. We introduce a 'new' flag to
indicate that we are going to use a new route and we release the
old route only if we replace it by a new one.

Reported-by: Julian Anastasov <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: Add a socket release callback for datagram sockets
Steffen Klassert [Mon, 21 Jan 2013 02:00:03 +0000 (02:00 +0000)]
ipv4: Add a socket release callback for datagram sockets

[ Upstream commit 8141ed9fcedb278f4a3a78680591bef1e55f75fb ]

This implements a socket release callback function to check
if the socket cached route got invalid during the time
we owned the socket. The function is used from udp, raw
and ping sockets.

Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: Invalidate the socket cached route on pmtu events if possible
Steffen Klassert [Mon, 21 Jan 2013 01:59:11 +0000 (01:59 +0000)]
ipv4: Invalidate the socket cached route on pmtu events if possible

[ Upstream commit 9cb3a50c5f63ed745702972f66eaee8767659acd ]

The route lookup in ipv4_sk_update_pmtu() might return a route
different from the route we cached at the socket. This is because
standart routes are per cpu, so each cpu has it's own struct rtable.
This means that we do not invalidate the socket cached route if the
NET_RX_SOFTIRQ is not served by the same cpu that the sending socket
uses. As a result, the cached route reused until we disconnect.

With this patch we invalidate the socket cached route if possible.
If the socket is owened by the user, we can't update the cached
route directly. A followup patch will implement socket release
callback functions for datagram sockets to handle this case.

Reported-by: Yurij M. Plotnikov <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: Add an error handler for icmp6
Steffen Klassert [Wed, 16 Jan 2013 22:09:49 +0000 (22:09 +0000)]
ipv6: Add an error handler for icmp6

[ Upstream commit 6f809da27c94425e07be4a64d5093e1df95188e9 ]

pmtu and redirect events are now handled in the protocols error handler,
so add an error handler for icmp6 to do this. It is needed in the case
when we have no socket context. Based on a patch by Duan Jiong.

Reported-by: Duan Jiong <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: Don't update the pmtu on mtu locked routes
Steffen Klassert [Wed, 16 Jan 2013 20:58:10 +0000 (20:58 +0000)]
ipv4: Don't update the pmtu on mtu locked routes

[ Upstream commit fa1e492aa3cbafba9f8fc6d05e5b08a3091daf4a ]

Routes with locked mtu should not use learned pmtu informations,
so do not update the pmtu on these routes.

Reported-by: Julian Anastasov <>
Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv4: Remove output route check in ipv4_mtu
Steffen Klassert [Wed, 16 Jan 2013 20:55:01 +0000 (20:55 +0000)]
ipv4: Remove output route check in ipv4_mtu

[ Upstream commit 38d523e2948162776903349c89d65f7b9370dadb ]

The output route check was introduced with git commit 261663b0
(ipv4: Don't use the cached pmtu informations for input routes)
during times when we cached the pmtu informations on the
inetpeer. Now the pmtu informations are back in the routes,
so this check is obsolete. It also had some unwanted side effects,
as reported by Timo Teras and Lukas Tribus.

Signed-off-by: Steffen Klassert <>
Acked-by: Timo Teräs <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonetback: correct netbk_tx_err to handle wrap around.
Ian Campbell [Wed, 6 Feb 2013 23:41:38 +0000 (23:41 +0000)]
netback: correct netbk_tx_err to handle wrap around.

[ Upstream commit b9149729ebdcfce63f853aa54a404c6a8f6ebbf3 ]

Signed-off-by: Ian Campbell <>
Acked-by: Jan Beulich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen/netback: free already allocated memory on failure in xen_netbk_get_requests
Ian Campbell [Wed, 6 Feb 2013 23:41:37 +0000 (23:41 +0000)]
xen/netback: free already allocated memory on failure in xen_netbk_get_requests

[ Upstream commit 4cc7c1cb7b11b6f3515bd9075527576a1eecc4aa ]

Signed-off-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.
Matthew Daley [Wed, 6 Feb 2013 23:41:36 +0000 (23:41 +0000)]
xen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.

[ Upstream commit 7d5145d8eb2b9791533ffe4dc003b129b9696c48 ]

Signed-off-by: Matthew Daley <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Acked-by: Ian Campbell <>
Acked-by: Jan Beulich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxen/netback: shutdown the ring if it contains garbage.
Ian Campbell [Wed, 6 Feb 2013 23:41:35 +0000 (23:41 +0000)]
xen/netback: shutdown the ring if it contains garbage.

[ Upstream commit 48856286b64e4b66ec62b94e504d0b29c1ade664 ]

A buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown

This fixes at least one known DoS/softlockup of the backend domain.

Signed-off-by: Ian Campbell <>
Reviewed-by: Konrad Rzeszutek Wilk <>
Acked-by: Jan Beulich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoatm/iphase: rename fregt_t -> ffreg_t
Heiko Carstens [Fri, 8 Feb 2013 00:19:11 +0000 (00:19 +0000)]
atm/iphase: rename fregt_t -> ffreg_t

[ Upstream commit ab54ee80aa7585f9666ff4dd665441d7ce41f1e8 ]

We have conflicting type qualifiers for "freg_t" in s390's ptrace.h and the
iphase atm device driver, which causes the compile error below.
Unfortunately the s390 typedef can't be renamed, since it's a user visible api,
nor can I change the include order in s390 code to avoid the conflict.

So simply rename the iphase typedef to a new name. Fixes this compile error:

In file included from drivers/atm/iphase.c:66:0:
drivers/atm/iphase.h:639:25: error: conflicting type qualifiers for 'freg_t'
In file included from next/arch/s390/include/asm/ptrace.h:9:0,
                 from next/arch/s390/include/asm/lowcore.h:12,
                 from next/arch/s390/include/asm/thread_info.h:30,
                 from include/linux/thread_info.h:54,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:29,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from drivers/atm/iphase.c:43:
next/arch/s390/include/uapi/asm/ptrace.h:197:3: note: previous declaration of 'freg_t' was here

Signed-off-by: Heiko Carstens <>
Acked-by: chas williams - CONTRACTOR <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6/ip6_gre: fix error case handling in ip6gre_tunnel_xmit()
Tommi Rantala [Wed, 6 Feb 2013 03:24:02 +0000 (03:24 +0000)]
ipv6/ip6_gre: fix error case handling in ip6gre_tunnel_xmit()

[ Upstream commit 41ab3e31bd50b42c85ac0aa0469642866aee2a9a ]

ip6gre_tunnel_xmit() is leaking the skb when we hit this error branch,
and the -1 return value from this function is bogus. Use the error
handling we already have in place in ip6gre_tunnel_xmit() for this error
case to fix this.

Signed-off-by: Tommi Rantala <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopacket: fix leakage of tx_ring memory
Phil Sutter [Fri, 1 Feb 2013 07:21:41 +0000 (07:21 +0000)]
packet: fix leakage of tx_ring memory

[ Upstream commit 9665d5d62487e8e7b1f546c00e11107155384b9a ]

When releasing a packet socket, the routine packet_set_ring() is reused
to free rings instead of allocating them. But when calling it for the
first time, it fills req->tp_block_nr with the value of rb->pg_vec_len
which in the second invocation makes it bail out since req->tp_block_nr
is greater zero but req->tp_block_size is zero.

This patch solves the problem by passing a zeroed auto-variable to
packet_set_ring() upon each invocation from packet_release().

As far as I can tell, this issue exists even since 69e3c75 (net: TX_RING
and packet mmap), i.e. the original inclusion of TX ring support into
af_packet, but applies only to sockets with both RX and TX ring
allocated, which is probably why this was unnoticed all the time.

Signed-off-by: Phil Sutter <>
Cc: Johann Baudy <>
Cc: Daniel Borkmann <>
Acked-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovia-rhine: Fix bugs in NAPI support.
David S. Miller [Wed, 30 Jan 2013 03:58:04 +0000 (22:58 -0500)]
via-rhine: Fix bugs in NAPI support.

[ Upstream commit 559bcac35facfed49ab4f408e162971612dcfdf3 ]

1) rhine_tx() should use dev_kfree_skb() not dev_kfree_skb_irq()

2) rhine_slow_event_task's NAPI triggering logic is racey, it
   should just hit the interrupt mask register.  This is the
   same as commit 7dbb491878a2c51d372a8890fa45a8ff80358af1
   ("r8169: avoid NAPI scheduling delay.") made to fix the same
   problem in the r8169 driver.  From Francois Romieu.

Reported-by: Jamie Gloudon <>
Tested-by: Jamie Gloudon <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: do not create neighbor entries for local delivery
Marcelo Ricardo Leitner [Tue, 29 Jan 2013 22:26:08 +0000 (22:26 +0000)]
ipv6: do not create neighbor entries for local delivery

[ Upstream commit bd30e947207e2ea0ff2c08f5b4a03025ddce48d3 ]

They will be created at output, if ever needed. This avoids creating
empty neighbor entries when TPROXYing/Forwarding packets for addresses
that are not even directly reachable.

Note that IPv4 already handles it this way. No neighbor entries are
created for local input.

Tested by myself and customer.

Signed-off-by: Jiri Pirko <>
Signed-off-by: Marcelo Ricardo Leitner <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agopktgen: correctly handle failures when adding a device
Cong Wang [Sun, 27 Jan 2013 21:14:08 +0000 (21:14 +0000)]
pktgen: correctly handle failures when adding a device

[ Upstream commit 604dfd6efc9b79bce432f2394791708d8e8f6efc ]

The return value of pktgen_add_device() is not checked, so
even if we fail to add some device, for example, non-exist one,
we still see "OK:...". This patch fixes it.

After this patch, I got:

# echo "add_device non-exist" > /proc/net/pktgen/kpktgend_0
-bash: echo: write error: No such device
# cat /proc/net/pktgen/kpktgend_0
Result: ERROR: can not add device non-exist
# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
# cat /proc/net/pktgen/kpktgend_0
Stopped: eth0
Result: OK: add_device=eth0

(Candidate for -stable)

Cc: David S. Miller <>
Signed-off-by: Cong Wang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoIP_GRE: Fix kernel panic in IP_GRE with GRE csum.
Pravin B Shelar [Wed, 23 Jan 2013 11:45:42 +0000 (11:45 +0000)]
IP_GRE: Fix kernel panic in IP_GRE with GRE csum.

[ Upstream commit 5465740ace36f179de5bb0ccb5d46ddeb945e309 ]

Due to IP_GRE GSO support, GRE can recieve non linear skb which
results in panic in case of GRE_CSUM.  Following patch fixes it by
using correct csum API.

Bug introduced in commit 6b78f16e4bdde3936b (gre: add GSO support)

Signed-off-by: Pravin B Shelar <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: loopback: fix a dst refcounting issue
Eric Dumazet [Fri, 25 Jan 2013 07:44:41 +0000 (07:44 +0000)]
net: loopback: fix a dst refcounting issue

[ Upstream commit 794ed393b707f01858f5ebe2ae5eabaf89d00022 ]

Ben Greear reported crashes in ip_rcv_finish() on a stress
test involving many macvlans.

We tracked the bug to a dst use after free. ip_rcv_finish()
was calling dst->input() and got garbage for dst->input value.

It appears the bug is in loopback driver, lacking
a skb_dst_force() before calling netif_rx().

As a result, a non refcounted dst, normally protected by a
RCU read_lock section, was escaping this section and could
be freed before the packet being processed.

  [<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
  [<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
  [<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
  [<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
  [<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
  [<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
  [<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
  [<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
  [<ffffffff814ad90e>] ip_finish_output+0x63/0x68
  [<ffffffff814ae412>] ip_output+0x61/0x67
  [<ffffffff814ab904>] dst_output+0x17/0x1b
  [<ffffffff814adb6d>] ip_local_out+0x1e/0x23
  [<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
  [<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
  [<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
  [<ffffffff814c3571>] tcp_connect+0x53c/0x587
  [<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
  [<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
  [<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
  [<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
  [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
  [<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
  [<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
  [<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
  [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
  [<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
  [<ffffffff814632c6>] sys_connect+0x75/0x98

This bug was introduced in linux-2.6.35, in commit
7fee226ad2397b (net: add a noref bit on skb dst)

skb_dst_force() is enforced in dev_queue_xmit() for devices having a

Reported-by: Ben Greear <>
Signed-off-by: Eric Dumazet <>
Tested-by: Ben Greear <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agor8169: remove the obsolete and incorrect AMD workaround
Timo Teräs [Mon, 21 Jan 2013 22:30:35 +0000 (22:30 +0000)]
r8169: remove the obsolete and incorrect AMD workaround

[ Upstream commit 5d0feaff230c0abfe4a112e6f09f096ed99e0b2d ]

This was introduced in commit 6dccd16 "r8169: merge with version
6.001.00 of Realtek's r8169 driver". I did not find the version
6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
this hunk is no longer present.

Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
rev d" claims to have fixed this issue otherwise.

The magic compare mask of 0xfffe000 is dubious as it masks
parts of the Reserved part, and parts of the VLAN tag. But this
does not make much sense as the VLAN tag parts are perfectly
valid there. In matter of fact this seems to be triggered with
any VLAN tagged packet as RxVlanTag bit is matched. I would
suspect 0xfffe0000 was intended to test reserved part only.

Finally, this hunk is evil as it can cause more packets to be
handled than what was NAPI quota causing net/core/dev.c:
net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
mess up the NAPI state causing device to hang.

As result, any system using VLANs and having high receive
traffic (so that NAPI poll budget limits rtl_rx) would result
in device hang.

Signed-off-by: Timo Teräs <>
Acked-by: Francois Romieu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonetxen: fix off by one bug in netxen_release_tx_buffer()
Eric Dumazet [Tue, 22 Jan 2013 06:33:05 +0000 (06:33 +0000)]
netxen: fix off by one bug in netxen_release_tx_buffer()

[ Upstream commit a05948f296ce103989b28a2606e47d2e287c3c89 ]

Christoph Paasch found netxen could trigger a BUG in its dismantle
phase, in netxen_release_tx_buffer(), using full size TSO packets.

cmd_buf->frag_count includes the skb->data part, so the loop must
start at index 1 instead of 0, or else we can make an out
of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]

Christoph provided the fixes in netxen_map_tx_skb() function.
In case of a dma mapping error, its better to clear the dma fields
so that we don't try to unmap them again in netxen_release_tx_buffer()

Reported-by: Christoph Paasch <>
Signed-off-by: Eric Dumazet <>
Tested-by: Christoph Paasch <>
Cc: Sony Chacko <>
Cc: Rajesh Borundia <>
Signed-off-by: Christoph Paasch <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoisdn/gigaset: fix zero size border case in debug dump
Tilman Schmidt [Mon, 21 Jan 2013 11:57:21 +0000 (11:57 +0000)]
isdn/gigaset: fix zero size border case in debug dump

[ Upstream commit d721a1752ba544df8d7d36959038b26bc92bdf80 ]

If subtracting 12 from l leaves zero we'd do a zero size allocation,
leading to an oops later when we try to set the NUL terminator.

Reported-by: Dan Carpenter <>
Signed-off-by: Tilman Schmidt <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: fix incorrect LOCKDROPPEDICMPS counter
Eric Dumazet [Sat, 19 Jan 2013 16:10:37 +0000 (16:10 +0000)]
tcp: fix incorrect LOCKDROPPEDICMPS counter

[ Upstream commit b74aa930ef49a3c0d8e4c1987f89decac768fb2c ]

commit 563d34d057 (tcp: dont drop MTU reduction indications)
added an error leading to incorrect accounting of

If socket is owned by the user, we want to increment
this SNMP counter, unless the message is a

Reported-by: Maciej ¯enczykowski <>
Signed-off-by: Eric Dumazet <>
Cc: Neal Cardwell <>
Signed-off-by: Maciej ¯enczykowski <>
Acked-by: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet/mlx4_core: Set number of msix vectors under SRIOV mode to firmware defaults
Or Gerlitz [Thu, 17 Jan 2013 05:30:43 +0000 (05:30 +0000)]
net/mlx4_core: Set number of msix vectors under SRIOV mode to firmware defaults

[ Upstream commit ca4c7b35f75492de7fbf5ee95be07481c348caee ]

The lines

if (mlx4_is_mfunc(dev)) {
nreq = 2;
} else {

which hard code the number of requested msi-x vectors under multi-function
mode to two can be removed completely, since the firmware sets num_eqs and
reserved_eqs appropriately Thus, the code line:

nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs, nreq);

is by itself sufficient and correct for all cases. Currently, for mfunc
mode num_eqs = 32 and reserved_eqs = 28, hence four vectors will be enabled.

This triples (one vector is used for the async events and commands EQ) the
horse power provided for processing of incoming packets on netdev RSS scheme,
IO initiators/targets commands processing flows, etc.

Reviewed-by: Jack Morgenstein <>
Signed-off-by: Amir Vadai <>
Signed-off-by: Or Gerlitz <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode
Yan Burman [Thu, 17 Jan 2013 05:30:42 +0000 (05:30 +0000)]
net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode

[ Upstream commit 213815a1e6ae70b9648483b110bc5081795f99e8 ]

Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
same host" introduced a regression under which a bridge acting as vSwitch
whose uplink is an mlx4 Ethernet device become non-operative in native
(non sriov) mode. This happens since broadcast ARP requests sent by VMs
were loopback-ed by the HW and hence the bridge learned VM source MACs
on both the VM and the uplink ports.

The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
configuration or when the device is in selftest.

Reviewed-by: Or Gerlitz <>
Signed-off-by: Yan Burman <>
Signed-off-by: Amir Vadai <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: calxedaxgmac: throw away overrun frames
Rob Herring [Wed, 16 Jan 2013 13:36:37 +0000 (13:36 +0000)]
net: calxedaxgmac: throw away overrun frames

[ Upstream commit d6fb3be544b46a7611a3373fcaa62b5b0be01888 ]

The xgmac driver assumes 1 frame per descriptor. If a frame larger than
the descriptor's buffer size is received, the frame will spill over into
the next descriptor. So check for received frames that span more than one
descriptor and discard them. This prevents a crash if we receive erroneous
large packets.

Signed-off-by: Rob Herring <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomacvlan: fix macvlan_get_size()
Eric Dumazet [Thu, 17 Jan 2013 21:30:49 +0000 (13:30 -0800)]
macvlan: fix macvlan_get_size()

[ Upstream commit 01fe944f1024bd4e5c327ddbe8d657656b66af2f ]

commit df8ef8f3aaa (macvlan: add FDB bridge ops and macvlan flags)
forgot to update macvlan_get_size() after the addition of

Signed-off-by: Eric Dumazet <>
Cc: John Fastabend <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: fix header length calculation in ip6_append_data()
Romain KUNTZ [Wed, 16 Jan 2013 12:47:40 +0000 (12:47 +0000)]
ipv6: fix header length calculation in ip6_append_data()

[ Upstream commit 7efdba5bd9a2f3e2059beeb45c9fa55eefe1bced ]

Commit 299b0767 (ipv6: Fix IPsec slowpath fragmentation problem)
has introduced a error in the header length calculation that
provokes corrupted packets when non-fragmentable extensions
headers (Destination Option or Routing Header Type 2) are used.

rt->rt6i_nfheader_len is the length of the non-fragmentable
extension header, and it should be substracted to
rt->dst.header_len, and not to exthdrlen, as it was done before
commit 299b0767.

This patch reverts to the original and correct behavior. It has
been successfully tested with and without IPsec on packets
that include non-fragmentable extensions headers.

Signed-off-by: Romain Kuntz <>
Acked-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoMAINTAINERS: Stephen Hemminger email change
Stephen Hemminger [Wed, 16 Jan 2013 17:55:57 +0000 (09:55 -0800)]
MAINTAINERS: Stephen Hemminger email change

[ Upstream commit adbbf69d1a54abf424e91875746a610dcc80017d ]

I changed my email because the mail server is now
redirected to; and the Brocade mail system
is not friendly to Linux desktop users.

Signed-off-by: Stephen Hemminger <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agotcp: fix a panic on UP machines in reqsk_fastopen_remove
Eric Dumazet [Sun, 13 Jan 2013 18:21:51 +0000 (18:21 +0000)]
tcp: fix a panic on UP machines in reqsk_fastopen_remove

[ Upstream commit cce894bb824429fd312706c7012acae43e725865 ]

spin_is_locked() on a non !SMP build is kind of useless.

BUG_ON(!spin_is_locked(xx)) is guaranteed to crash.

Just remove this check in reqsk_fastopen_remove() as
the callers do hold the socket lock.

Reported-by: Ketan Kulkarni <>
Signed-off-by: Eric Dumazet <>
Cc: Jerry Chu <>
Cc: Yuchung Cheng <>
Cc: Dave Taht <>
Acked-by: H.K. Jerry Chu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet, wireless: overwrite default_ethtool_ops
Stanislaw Gruszka [Thu, 10 Jan 2013 23:19:10 +0000 (23:19 +0000)]
net, wireless: overwrite default_ethtool_ops

[ Upstream commit d07d7507bfb4e23735c9b83e397c43e1e8a173e8 ]


commit 2c60db037034d27f8c636403355d52872da92f81
Author: Eric Dumazet <>
Date:   Sun Sep 16 09:17:26 2012 +0000

    net: provide a default dev->ethtool_ops

wireless core does not correctly assign ethtool_ops.

After alloc_netdev*() call, some cfg80211 drivers provide they own
ethtool_ops, but some do not. For them, wireless core provide generic
cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:

        if (!dev->ethtool_ops)
                dev->ethtool_ops = &cfg80211_ethtool_ops;

But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
drivers without custom ethtool_ops), but points to &default_ethtool_ops.

In order to fix the problem, provide function which will overwrite
default_ethtool_ops and use it by wireless core.

Signed-off-by: Stanislaw Gruszka <>
Acked-by: Johannes Berg <>
Acked-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoipv6: fix the noflags test in addrconf_get_prefix_route
Romain Kuntz [Wed, 9 Jan 2013 14:02:26 +0000 (15:02 +0100)]
ipv6: fix the noflags test in addrconf_get_prefix_route

[ Upstream commit 85da53bf1c336bb07ac038fb951403ab0478d2c5 ]

The tests on the flags in addrconf_get_prefix_route() does no make
much sense: the 'noflags' parameter contains the set of flags that
must not match with the route flags, so the test must be done
against 'noflags', and not against 'flags'.

Signed-off-by: Romain Kuntz <>
Acked-by: YOSHIFUJI Hideaki <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonet: prevent setting ttl=0 via IP_TTL
Cong Wang [Mon, 7 Jan 2013 21:17:00 +0000 (21:17 +0000)]
net: prevent setting ttl=0 via IP_TTL

[ Upstream commit c9be4a5c49cf51cc70a993f004c5bb30067a65ce ]

A regression is introduced by the following commit:

commit 4d52cfbef6266092d535237ba5a4b981458ab171
Author: Eric Dumazet <>
Date:   Tue Jun 2 00:42:16 2009 -0700

    net: ipv4/ip_sockglue.c cleanups

    Pure cleanups

but it is not a pure cleanup...

-               if (val != -1 && (val < 1 || val>255))
+               if (val != -1 && (val < 0 || val > 255))

Since there is no reason provided to allow ttl=0, change it back.

Reported-by: nitin padalia <>
Cc: nitin padalia <>
Cc: Eric Dumazet <>
Cc: David S. Miller <>
Signed-off-by: Cong Wang <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodm thin: fix queue limits stacking
Mike Snitzer [Thu, 31 Jan 2013 14:11:14 +0000 (14:11 +0000)]
dm thin: fix queue limits stacking

commit 0f640dca08330dfc7820d610578e5935b5e654b2 upstream.

thin_io_hints() is blindly copying the queue limits from the thin-pool
which can lead to incorrect limits being set.  The fix here simply
deletes the thin_io_hints() hook which leaves the existing stacking
infrastructure to set the limits correctly.

When a thin-pool uses an MD device for the data device a thin device
from the thin-pool must respect MD's constraints about disallowing a bio
from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
chunksize is 1152K and thin-pool chunksize is 256K I see the following
md/raid0 error (with extra debug tracing added to thin_endio) when
mkfs.xfs is executed against the thin device:

md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0

This extra DM debugging shows that the failing bio is spanning across
the first and second logical 1152K chunk (sector 2080 + 255 takes the
bio beyond the first chunk's boundary of sector 2304).  So the bio
splitting that DM is doing clearly isn't respecting the MD limits.

max_hw_sectors_kb is 127 for both the thin-pool and thin device
(queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
precision).  So this explains why bi_size is 130560.

But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
that it doesn't have a .merge function (for bio_add_page to consult
indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
device that has a compulsory merge_bvec_fn.  This scenario is exactly
why DM must resort to sending single PAGE_SIZE bios to the underlying
layer. Some additional context for this is available in the header for
commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").

Long story short, the reason a thin device doesn't properly get
configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
thin_io_hints() is blindly copying the queue limits from the thin-pool
device directly to the thin device's queue limits.

Fix this by eliminating thin_io_hints.  Doing so is safe because the
block layer's queue limits stacking already enables the upper level thin
device to inherit the thin-pool device's discard and minimum_io_size and
optimal_io_size limits that get set in pool_io_hints.  But avoiding the
queue limits copy allows the thin and thin-pool limits to be different
where it is important, namely max_hw_sectors_kb.

Reported-by: Daniel Browning <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomfd: db8500-prcmu: Fix irqdomain usage
Linus Walleij [Thu, 20 Dec 2012 09:20:15 +0000 (10:20 +0100)]
mfd: db8500-prcmu: Fix irqdomain usage

commit 89d9b1c99374997d68910ba49d5b7df80e7f2061 upstream.

This fixes two issues with the DB8500 PRCMU irqdomain:
- You have to state the irq base 0 to get a linear domain
  for the DT case from irq_domain_add_simple()
- The irqdomain was not used to translate the initial irq
  request using irq_create_mapping() making the linear
  case fail as it was lacking a proper descriptor.

I took this opportunity to fix two lines of whitespace
errors in related code as I was anyway messing around with

Acked-by Lee Jones <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Samuel Ortiz <>
Signed-off-by: CAI Qian <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoath9k_hw: fix calibration issues on chainmask that don't include chain 0
Felix Fietkau [Sun, 20 Jan 2013 20:55:20 +0000 (21:55 +0100)]
ath9k_hw: fix calibration issues on chainmask that don't include chain 0

commit 4a8f199508d79ff8a7d1e22f47b912baaf225336 upstream.

Signed-off-by: Felix Fietkau <>
Signed-off-by: John W. Linville <>
Signed-off-by: CAI Qian <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomedia: pwc-if: must check vb2_queue_init() success
Mauro Carvalho Chehab [Sat, 27 Oct 2012 17:26:25 +0000 (14:26 -0300)]
media: pwc-if: must check vb2_queue_init() success

commit eda94710d6502672c5ee7de198fa78a63ddfae3a upstream.

drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
drivers/media/usb/pwc/pwc-if.c:1003:16: warning: ignoring return value of 'vb2_queue_init', declared with attribute warn_unused_result [-Wunused-result]
In the past, it used to have a logic there at queue init that would
BUG() on errors. This logic got removed. Drivers are now required
to explicitly handle the queue initialization errors, or very bad
things may happen.

Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Paul Bolle <>
5 years agoe1000e: enable ECC on I217/I218 to catch packet buffer memory errors
Bruce Allan [Mon, 28 Jan 2013 00:43:48 +0000 (00:43 +0000)]
e1000e: enable ECC on I217/I218 to catch packet buffer memory errors

commit 286003048aaef49b26bb9d93611dc69085e8982e upstream.

In rare instances, memory errors have been detected in the internal packet
buffer memory on I217/I218 when stressed under certain environmental
conditions.  Enable Error Correcting Code (ECC) in hardware to catch both
correctable and uncorrectable errors.  Correctable errors will be handled
by the hardware.  Uncorrectable errors in the packet buffer will cause the
packet to be received with an error indication in the buffer descriptor
causing the packet to be discarded.  If the uncorrectable error is in the
descriptor itself, the hardware will stop and interrupt the driver
indicating the error.  The driver will then reset the hardware in order to
clear the error and restart.

Both types of errors will be accounted for in statistics counters.

Signed-off-by: Bruce Allan <>
Tested-by: Jeff Pieper <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomwifiex: fix incomplete scan in case of IE parsing error
Bing Zhao [Tue, 29 Jan 2013 22:38:02 +0000 (14:38 -0800)]
mwifiex: fix incomplete scan in case of IE parsing error

commit 8a7d7cbf7b5ff9912ef50b3e94c9ad9f37b1c75f upstream.

A scan request is split into multiple scan commands queued in
scan_pending_q. Each scan command will be sent to firmware and
its response is handlded one after another.

If any error is detected while parsing IE in command response
buffer the remaining data will be ignored and error is returned.

We should check if there is any more scan commands pending in
the queue before returning error. This ensures that we will call
cfg80211_scan_done if this is the last scan command, or send
next scan command in scan_pending_q to firmware.

Signed-off-by: Bing Zhao <>
Signed-off-by: Amitkumar Karwar <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agocan: c_can: Set reserved bit in IFx_MASK2 to 1 on write
Alexander Stein [Thu, 13 Dec 2012 09:06:10 +0000 (10:06 +0100)]
can: c_can: Set reserved bit in IFx_MASK2 to 1 on write

commit 2bd3bc4e8472424f1a6009825397639a8968920a upstream.

According to C_CAN documentation, the reserved bit in IFx_MASK2 register is
fixed 1.

Signed-off-by: Alexander Stein <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoRevert "iwlwifi: fix the reclaimed packet tracking upon flush queue"
Emmanuel Grumbach [Mon, 21 Jan 2013 11:12:57 +0000 (13:12 +0200)]
Revert "iwlwifi: fix the reclaimed packet tracking upon flush queue"

commit ae023b2795d36f0f077e157428eb7eafa29ee412 upstream.

This reverts commit f590dcec944552f9a4a61155810f3abd17d6465d
which has been reported to cause issues.

See for further details.

Signed-off-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoBluetooth: Fix handling of unexpected SMP PDUs
Johan Hedberg [Tue, 29 Jan 2013 16:44:23 +0000 (10:44 -0600)]
Bluetooth: Fix handling of unexpected SMP PDUs

commit 8cf9fa1240229cbdd888236c0c43fcbad680cf00 upstream.

The conn->smp_chan pointer can be NULL if SMP PDUs arrive at unexpected
moments. To avoid NULL pointer dereferences the code should be checking
for this and disconnect if an unexpected SMP PDU arrives. This patch
fixes the issue by adding a check for conn->smp_chan for all other PDUs
except pairing request and security request (which are are the first
PDUs to come to initialize the SMP context).

Signed-off-by: Johan Hedberg <>
Acked-by: Marcel Holtmann <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agovirtio_console: Don't access uninitialized data.
Sjur Brændeland [Mon, 21 Jan 2013 23:20:26 +0000 (09:50 +1030)]
virtio_console: Don't access uninitialized data.

commit aded024a12b32fc1ed9a80639681daae2d07ec25 upstream.

Don't access uninitialized work-queue when removing device.
The work queue is initialized only if the device multi-queue.
So don't call cancel_work unless this is a multi-queue device.

This fixes the following panic:

Kernel panic - not syncing: BUG!
Call Trace:
62031b28:  [<6026085d>] panic+0x16b/0x2d3
62031b30:  [<6004ef5e>] flush_work+0x0/0x1d7
62031b60:  [<602606f2>] panic+0x0/0x2d3
62031b68:  [<600333b0>] memcpy+0x0/0x140
62031b80:  [<6002d58a>] unblock_signals+0x0/0x84
62031ba0:  [<602609c5>] printk+0x0/0xa0
62031bd8:  [<60264e51>] __mutex_unlock_slowpath+0x13d/0x148
62031c10:  [<6004ef5e>] flush_work+0x0/0x1d7
62031c18:  [<60050234>] try_to_grab_pending+0x0/0x17e
62031c38:  [<6004e984>] get_work_gcwq+0x71/0x8f
62031c48:  [<60050539>] __cancel_work_timer+0x5b/0x115
62031c78:  [<628acc85>] unplug_port+0x0/0x191 [virtio_console]
62031c98:  [<6005061c>] cancel_work_sync+0x12/0x14
62031ca8:  [<628ace96>] virtcons_remove+0x80/0x15c [virtio_console]
62031ce8:  [<628191de>] virtio_dev_remove+0x1e/0x7e [virtio]
62031d08:  [<601cf242>] __device_release_driver+0x75/0xe4
62031d28:  [<601cf2dd>] device_release_driver+0x2c/0x40
62031d48:  [<601ce0dd>] driver_unbind+0x7d/0xc6
62031d88:  [<601cd5d9>] drv_attr_store+0x27/0x29
62031d98:  [<60115f61>] sysfs_write_file+0x100/0x14d
62031df8:  [<600b737d>] vfs_write+0xcb/0x184
62031e08:  [<600b58b8>] filp_close+0x88/0x94
62031e38:  [<600b7686>] sys_write+0x59/0x88
62031e88:  [<6001ced1>] handle_syscall+0x5d/0x80
62031ea8:  [<60030a74>] userspace+0x405/0x531
62031f08:  [<600d32cc>] sys_dup+0x0/0x5e
62031f28:  [<601b11d6>] strcpy+0x0/0x18
62031f38:  [<600be46c>] do_execve+0x10/0x12
62031f48:  [<600184c7>] run_init_process+0x43/0x45
62031fd8:  [<60019a91>] new_thread_handler+0xba/0xbc

Signed-off-by: Sjur Brændeland <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoIB/qib: Fix for broken sparse warning fix
Mike Marciniszyn [Thu, 24 Jan 2013 18:59:34 +0000 (18:59 +0000)]
IB/qib: Fix for broken sparse warning fix

commit d359f35430c4ea4dd4e24d809aeaeff1fa54c314 upstream.

Commit 1fb9fed6d489 ("IB/qib: Fix QP RCU sparse warning") broke QP
hash list deletion in qp_remove() badly.

This patch restores the former for loop behavior, while still fixing
the sparse warnings.

Reviewed-by: Gary Leshner <>
Signed-off-by: Mike Marciniszyn <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoregulator: s2mps11: fix incorrect register for buck10
Alim Akhtar [Wed, 30 Jan 2013 13:02:27 +0000 (08:02 -0500)]
regulator: s2mps11: fix incorrect register for buck10

commit c76edd52bf19c9d01da7edc4ff04d3707c299779 upstream.

For BUCK10 the control registers are wrongly set as buck9 control register
This patch corrects the control registers for buck10

Signed-off-by: Alim Akhtar <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoregulator: clear state each invocation of of_regulator_match
Stephen Warren [Tue, 29 Jan 2013 19:01:13 +0000 (12:01 -0700)]
regulator: clear state each invocation of of_regulator_match

commit a2f95c363701deba2205f81929b40222ea6f4f80 upstream.

of_regulator_match() saves some dynamcially allocated state into the
match table that's passed to it. By implementation and not contract, for
each match table entry, if non-NULL state is already present,
of_regulator_match() will not overwrite it. of_regulator_match() is
typically called each time a regulator is probe()d. This means it is
called with the same match table over and over again if a regulator
triggers deferred probe. This results in stale, kfree()d data being left
in the match table from probe to probe, which causes a variety of crashes
or use of invalid data.

Explicitly free all output state from of_regulator_match() before
generating new results in order to avoid this.

Signed-off-by: Stephen Warren <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoregulator: max8998: fix incorrect min_uV value for ldo10
Marek Szyprowski [Fri, 25 Jan 2013 08:25:40 +0000 (09:25 +0100)]
regulator: max8998: fix incorrect min_uV value for ldo10

commit 36a6f8c035760dcbd0c3acb4c2fd56268588a9cb upstream.

Correct value for minimal voltage for ldo10 output is 950000 uV. This
patch fixes the typo introduced by patch adf6178ad5552a7f2f742a8c85343c50
("regulator: max8998: Use uV in voltage_map_desc"), what solves broken
probe of max8998 in v3.8-rc4.

Signed-off-by: Marek Szyprowski <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agortlwifi: Fix scheduling while atomic bug
Larry Finger [Sat, 2 Feb 2013 21:55:00 +0000 (15:55 -0600)]
rtlwifi: Fix scheduling while atomic bug

commit a5ffbe0a1993a27072742ef7db6cf9839956fce9 upstream.

Kernel commits 41affd5 and 6539306 changed the locking in rtl_lps_leave()
from a spinlock to a mutex by doing the calls indirectly from a work queue
to reduce the time that interrupts were disabled. This change was fine for
most systems; however a scheduling while atomic bug was reported in The backtrace indicates
that routine rtl_is_special(), which calls rtl_lps_leave() in three places
was entered in atomic context. These direct calls are replaced by putting a
request on the appropriate work queue.

Signed-off-by: Larry Finger <>
Reported-and-tested-by: Nathaniel Doherty <>
Cc: Nathaniel Doherty <>
Cc: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agortlwifi: Fix the usage of the wrong variable in usb.c
Larry Finger [Sun, 27 Jan 2013 22:24:25 +0000 (16:24 -0600)]
rtlwifi: Fix the usage of the wrong variable in usb.c

commit 0a06ad8e3a1cb5311b7dbafde45410aa1bce9d40 upstream.

In routine _rtl_rx_pre_process(), skb_dequeue() is called to get an skb;
however, the wrong variable name is used in subsequent calls.

Reported-by: Guenter Roeck <>
Signed-off-by: Larry Finger <>
Cc: Guenter Roeck <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoLinux 3.7.7
Greg Kroah-Hartman [Mon, 11 Feb 2013 17:05:09 +0000 (09:05 -0800)]
Linux 3.7.7

5 years agoUSB: EHCI: fix for leaking isochronous data
Alan Stern [Wed, 30 Jan 2013 21:35:02 +0000 (16:35 -0500)]
USB: EHCI: fix for leaking isochronous data

commit b09a61cc0bc2a7151f4ab652489e85253d5d0175 upstream.

This patch (as1653) fixes a bug in ehci-hcd.  Unlike iTD entries, an
siTD entry in the periodic schedule may not complete until the frame
after the one it belongs to.  Consequently, when scanning the periodic
schedule it is necessary to start with the frame _preceding_ the one
where the previous scan ended.

Not doing this properly can result in memory leaks and failures to
complete isochronous URBs.

Signed-off-by: Alan Stern <>
Reported-and-tested-by: Andy Leiserson <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agousb: Prevent dead ports when xhci is not enabled
David Moore [Thu, 24 Jan 2013 06:19:49 +0000 (22:19 -0800)]
usb: Prevent dead ports when xhci is not enabled

commit 58b2939b4d5a030eaec469d29812ab8477ee7e76 upstream.

When the xHCI driver is not available, actively switch the ports to EHCI
mode since some BIOSes leave them in xHCI mode where they would
otherwise appear dead.  This was discovered on a  Dell Optiplex 7010,
but it's possible other systems could be affected.

This should be backported to kernels as old as 3.0, that contain the
commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: David Moore <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: XHCI: fix memory leak of URB-private data
Alan Stern [Thu, 17 Jan 2013 15:32:16 +0000 (10:32 -0500)]
USB: XHCI: fix memory leak of URB-private data

commit 48c3375c5f69b1c2ef3d1051a0009cb9bce0ce24 upstream.

This patch (as1640) fixes a memory leak in xhci-hcd.  The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers.  The patch adds a kfree() call so
that all paths end up freeing the memory properly.

This patch should be backported to kernels as old as 2.6.36, that
contain the commit 8e51adccd4c4b9ffcd509d7f2afce0a906139f75 "USB: xHCI:
Introduce urb_priv structure"

Signed-off-by: Alan Stern <>
Signed-off-by: Sarah Sharp <>
Reported-and-tested-by: Martin Mokrejs <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxhci: Fix TD size for isochronous URBs.
Sarah Sharp [Fri, 11 Jan 2013 21:36:35 +0000 (13:36 -0800)]
xhci: Fix TD size for isochronous URBs.

commit f18f8ed2a9adc41c2d9294b85b6af115829d2af1 upstream.

To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size.  Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field.  The TD size calculation did not mask off those bits before using
the field.  This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.

For example:
 - an isoc endpoint has 2 additional service opportunites and
   a max packet size of 1020 bytes
 - a frame transfer buffer contains 3060 bytes
 - one frame buffer crosses a 64KB boundary, and must be split into
   one 1276 byte TRB, and one 1784 byte TRB.

The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.

For this TD, the number of packets to be transferred is (3060 / 1020),
or 3.  The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder.  After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.

The old code would calculate the TD size for the first TRB as:

total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)

The math should have been:

total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2

Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as

total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1

Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format."  It may not apply well to kernels older
than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".

Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoxhci: Fix isoc TD encoding.
Sarah Sharp [Fri, 11 Jan 2013 19:19:07 +0000 (11:19 -0800)]
xhci: Fix isoc TD encoding.

commit 760973d2a74b93eb1697981f7448f0e62767cfc4 upstream.

An isochronous TD is comprised of one isochronous TRB chained to zero or
more normal TRBs.  Only the isoc TRB has the TBC and TLBPC fields.  The
normal TRBs must set those fields to zeroes.  The code was setting the
TBC and TLBPC fields for both isoc and normal TRBs.  Fix this.

This should be backported to stable kernels as old as 3.0, that contain
the commit b61d378f2da41c748aba6ca19d77e1e1c02bcea5 " xhci 1.0: Set
transfer burst last packet count field."

Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers: xhci: fix incorrect bit test
Nickolai Zeldovich [Tue, 8 Jan 2013 03:39:31 +0000 (22:39 -0500)]
drivers: xhci: fix incorrect bit test

commit ba7b5c22d33136a5612ca5ef8d31564dcc501126 upstream.

Fix incorrect bit test that originally showed up in
4ee823b83bc9851743fab756c76b27d6a1e2472b "USB/xHCI: Support
device-initiated USB 3.0 resume."

Use '&' instead of '&&'.

This should be backported to kernels as old as 3.4.

Signed-off-by: Nickolai Zeldovich <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: storage: optimize to match the Huawei USB storage devices and support new switch...
fangxiaozhi [Mon, 4 Feb 2013 07:16:34 +0000 (15:16 +0800)]
USB: storage: optimize to match the Huawei USB storage devices and support new switch command

commit 200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f upstream.

1. Optimize the match rules with new macro for Huawei USB storage devices,
   to avoid to load USB storage driver for the modem interface
   with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.

Signed-off-by: fangxiaozhi <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: storage: Define a new macro for USB storage match rules
fangxiaozhi [Mon, 4 Feb 2013 07:14:46 +0000 (15:14 +0800)]
USB: storage: Define a new macro for USB storage match rules

commit 07c7be3d87e5cdaf5f94c271c516456364ef286c upstream.

1. Define a new macro for USB storage match rules:
    matching with Vendor ID and interface descriptors.

Signed-off-by: fangxiaozhi <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agousb: Using correct way to clear usb3.0 device's remote wakeup feature.
Lan Tianyu [Thu, 24 Jan 2013 02:31:28 +0000 (10:31 +0800)]
usb: Using correct way to clear usb3.0 device's remote wakeup feature.

commit 54a3ac0c9e5b7213daa358ce74d154352657353a upstream.

Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.

This should be backported to kernels as old as 3.4, that contain the
commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote
wakeup for USB3 devices."

Signed-off-by: Lan Tianyu <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: EHCI: fix bug in scheduling periodic split transfers
Alan Stern [Wed, 30 Jan 2013 21:36:40 +0000 (16:36 -0500)]
USB: EHCI: fix bug in scheduling periodic split transfers

commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d upstream.

This patch (as1654) fixes a very old bug in ehci-hcd, connected with
scheduling of periodic split transfers.  The calculations for
full/low-speed bus usage are all carried out after the correction for
bit-stuffing has been applied, but the values in the max_tt_usecs
array assume it hasn't been.  The array should allow for allocation of
up to 90% of the bus capacity, which is 900 us, not 780 us.

The symptom caused by this bug is that any isochronous transfer to a
full-speed device with a maxpacket size larger than about 980 bytes is
always rejected with a -ENOSPC error.

Signed-off-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: EHCI: fix timer bug affecting port resume
Alan Stern [Fri, 25 Jan 2013 22:17:43 +0000 (17:17 -0500)]
USB: EHCI: fix timer bug affecting port resume

commit ee74290b7853db9d5fd64db70e5c175241c59fba upstream.

This patch (as1652) fixes a long-standing bug in ehci-hcd.  The driver
relies on status polls to know when to stop port-resume signalling.
It uses the root-hub status timer to schedule these status polls.  But
when the driver for the root hub is resumed, the timer is rescheduled
to go off immediately -- before the port is ready.  When this happens
the timer does not get re-enabled, which prevents the port resume from
finishing until some other event occurs.

The symptom is that when a new device is plugged in, it doesn't get
recognized or enumerated until lsusb is run or something else happens.

The solution is to re-enable the root-hub status timer after every
status poll while a port resume is in progress.

This bug hasn't surfaced before now because we never used to try to
suspend the root hub in the middle of a port resume (except by

Signed-off-by: Alan Stern <>
Reported-and-tested-by: Norbert Preining <>
Tested-by: Ming Lei <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: EHCI: unlink one async QH at a time
Alan Stern [Fri, 25 Jan 2013 21:54:22 +0000 (16:54 -0500)]
USB: EHCI: unlink one async QH at a time

commit 6e0c3339a6f19d748f16091d0a05adeb1e1f822b upstream.

This patch (as1648) fixes a regression affecting nVidia EHCI
controllers.  Evidently they don't like to have more than one async QH
unlinked at a time.  I can't imagine how they manage to mess it up,
but at least one of them does.

The patch changes the async unlink logic in two ways:

Each time an IAA cycle is started, only the first QH on the
async unlink list is handled (rather than all of them).

Async QHs do not all get unlinked as soon as they have been
empty for long enough.  Instead, only the last one (i.e., the
one that has been on the schedule the longest) is unlinked,
and then only if no other unlinks are in progress at the time.

This means that when multiple QHs are empty, they won't be unlinked as
quickly as before.  That's okay; it won't affect correct operation of
the driver or add an excessive load.  Multiple unlinks tend to be
relatively rare in any case.

Signed-off-by: Alan Stern <>
Reported-and-tested-by: Piergiorgio Sartor <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: EHCI: remove ASS/PSS polling timeout
Alan Stern [Fri, 25 Jan 2013 21:52:45 +0000 (16:52 -0500)]
USB: EHCI: remove ASS/PSS polling timeout

commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5 upstream.

This patch (as1647) attempts to work around a problem that seems to
affect some nVidia EHCI controllers.  They sometimes take a very long
time to turn off their async or periodic schedules.  I don't know if
this is a result of other problems, but in any case it seems wise not
to depend on schedule enables or disables taking effect in any
specific length of time.

The patch removes the existing 20-ms timeout for enabling and
disabling the schedules.  The driver will now continue to poll the
schedule state at 1-ms intervals until the controller finally decides
to obey the most recent command issued by the driver.  Just in case
this hides a problem, a debugging message will be logged if the
controller takes longer than 20 polls.

I don't know if this will actually fix anything, but it can't hurt.

Signed-off-by: Alan Stern <>
Tested-by: Piergiorgio Sartor <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: qcserial: add Telit Gobi QDL device
Daniele Palmas [Mon, 28 Jan 2013 15:48:54 +0000 (16:48 +0100)]
USB: qcserial: add Telit Gobi QDL device

commit 78796ae17eacedcdcaaeb03ba73d2e532a4c8f83 upstream.

Add VID and PID for Telit Gobi QDL device

Signed-off-by: Daniele Palmas <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: option: add Changhong CH690
Bjørn Mork [Fri, 1 Feb 2013 11:06:51 +0000 (12:06 +0100)]
USB: option: add Changhong CH690

commit d4fa681541aa7bf8570d03426dd7ba663a71c467 upstream.

New device with 3 serial interfaces:

 If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend) Sub=ff Prot=ff
 If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff
 If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff
 If#= 3 Alt= 0 #EPs= 2 Cls=08(stor) Sub=06 Prot=50

Signed-off-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: option: add support for Telit LE920
Daniele Palmas [Mon, 28 Jan 2013 15:47:10 +0000 (16:47 +0100)]
USB: option: add support for Telit LE920

commit 03eb466f276ceef9dcf023dc5474db02af68aad9 upstream.

Add PID and special handling for Telit LE920

Signed-off-by: Daniele Palmas <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II
Sven Killig [Fri, 1 Feb 2013 22:43:06 +0000 (23:43 +0100)]
USB: ftdi_sio: add PID/VID entries for ELV WS 300 PC II

commit c249f911406efcc7456cb4af79396726bf7b8c57 upstream.

Add PID/VID entries for ELV WS 300 PC II weather station

Signed-off-by: Sven Killig <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agoUSB: ftdi_sio: add Zolix FTDI PID
Petr Kubánek [Fri, 1 Feb 2013 16:24:04 +0000 (17:24 +0100)]
USB: ftdi_sio: add Zolix FTDI PID

commit 0ba3b2ccc72b3df5c305d61f59d93ab0f0e87991 upstream.

Add support for Zolix Omni 1509 monochromator custom USB-RS232 converter.

Signed-off-by: Petr Kubánek <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/rtc/rtc-pl031.c: fix the missing operation on enable
Haojian Zhuang [Mon, 4 Feb 2013 22:28:54 +0000 (14:28 -0800)]
drivers/rtc/rtc-pl031.c: fix the missing operation on enable

commit e7e034e18a0ab6bafb2425c3242cac311164f4d6 upstream.

The RTC control register should be enabled in the process of

Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC.  The
register mapping section in RTC is always read as zero.  So I doubt that
ST guys may already enable this register in bootloader.  So they won't
meet this issue.

Signed-off-by: Haojian Zhuang <>
Cc: Srinidhi Kasagar <>
Cc: Linus Walleij <>
Cc: Alessandro Zummo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler
Jan Luebbe [Mon, 4 Feb 2013 22:28:53 +0000 (14:28 -0800)]
drivers/rtc/rtc-isl1208.c: call rtc_update_irq() from the alarm irq handler

commit 72fca4a4b32dc778b5b885c3498700e42b610d49 upstream.

Previously the alarm event was not propagated into the RTC subsystem.
By adding a call to rtc_update_irq, this fixes a timeout problem with
the hwclock utility.

Signed-off-by: Jan Luebbe <>
Cc: Alessandro Zummo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agomm/hugetlb: set PTE as huge in hugetlb_change_protection and remove_migration_pte
Tony Lu [Mon, 4 Feb 2013 22:28:46 +0000 (14:28 -0800)]
mm/hugetlb: set PTE as huge in hugetlb_change_protection and remove_migration_pte

commit be7517d6ab9722f0abad6ba5ffd39cfced95549c upstream.

When setting a huge PTE, besides calling pte_mkhuge(), we also need to
call arch_make_huge_pte(), which we indeed do in make_huge_pte(), but we
forget to do in hugetlb_change_protection() and remove_migration_pte().

Signed-off-by: Zhigang Lu <>
Signed-off-by: Chris Metcalf <>
Reviewed-by: Michal Hocko <>
Acked-by: Hillf Danton <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agonilfs2: fix fix very long mount time issue
Vyacheslav Dubeyko [Mon, 4 Feb 2013 22:28:41 +0000 (14:28 -0800)]
nilfs2: fix fix very long mount time issue

commit a9bae189542e71f91e61a4428adf6e5a7dfe8063 upstream.

There exists a situation when GC can work in background alone without
any other filesystem activity during significant time.

The nilfs_clean_segments() method calls nilfs_segctor_construct() that
updates superblocks in the case of NILFS_SC_SUPER_ROOT and
THE_NILFS_DISCONTINUED flags are set.  But when GC is working alone the
nilfs_clean_segments() is called with unset THE_NILFS_DISCONTINUED flag.
As a result, the update of superblocks doesn't occurred all this time
and in the case of SPOR superblocks keep very old values of last super
root placement.


Trying to mount a NILFS2 volume after SPOR in such environment ends with
very long mounting time (it can achieve about several hours in some


1. It needs to use external USB HDD, disable automount and doesn't
   make any additional filesystem activity on the NILFS2 volume.

2. Generate temporary file with size about 100 - 500 GB (for example,
   dd if=/dev/zero of=<file_name> bs=1073741824 count=200).  The size of
   file defines duration of GC working.

3. Then it needs to delete file.

4. Start GC manually by means of command "nilfs-clean -p 0".  When you
   start GC by means of such way then, at the end, superblocks is updated
   by once.  So, for simulation of SPOR, it needs to wait sometime (15 -
   40 minutes) and simply switch off USB HDD manually.

5. Switch on USB HDD again and try to mount NILFS2 volume.  As a
   result, NILFS2 volume will mount during very long time.



This patch adds checking that superblocks need to update and set
THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call.

Reported-by: Sergey Alexandrov <>
Signed-off-by: Vyacheslav Dubeyko <>
Tested-by: Vyacheslav Dubeyko <>
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 agomtd: davinci_nand: fix modular build with CONFIG_OF=y
Sergei Shtylyov [Thu, 3 Jan 2013 18:27:34 +0000 (21:27 +0300)]
mtd: davinci_nand: fix modular build with CONFIG_OF=y

commit 7a9c83888761a9a26049b439dc0b09e7ea8a854b upstream.

Commit cdeadd712f52b16a9285386d61ee26fd14eb4085 (mtd: nand: davinci: add OF
support for davinci nand controller) has never been really build tested with
the driver as a module.  When the driver is built-in, the missing semicolon
after structure initializer is "compensated" by MODULE_DEVICE_TABLE() macro
being empty and so the initializer using the trailing semicolon on the next
line; when the driver is built as a module, compilation error ensues, and as
the 'davinci_all_defconfig' has the NAND driver modular, this error prevents
DaVinci family kernel from building...

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agosched/rt: Use root_domain of rt_rq not current processor
Shawn Bohrer [Mon, 14 Jan 2013 17:55:31 +0000 (11:55 -0600)]
sched/rt: Use root_domain of rt_rq not current processor

commit aa7f67304d1a03180f463258aa6f15a8b434e77d upstream.

When the system has multiple domains do_sched_rt_period_timer()
can run on any CPU and may iterate over all rt_rq in
cpu_online_mask.  This means when balance_runtime() is run for a
given rt_rq that rt_rq may be in a different rd than the current
processor.  Thus if we use smp_processor_id() to get rd in
do_balance_runtime() we may borrow runtime from a rt_rq that is
not part of our rd.

This changes do_balance_runtime to get the rd from the passed in
rt_rq ensuring that we borrow runtime only from the correct rd
for the given rt_rq.

This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime
when we try reclaim runtime lent to other rt_rq but runtime has
been lent to a rt_rq in another rd.

Signed-off-by: Shawn Bohrer <>
Acked-by: Steven Rostedt <>
Acked-by: Mike Galbraith <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agox86-64: Replace left over sti/cli in ia32 audit exit code
Jan Beulich [Wed, 30 Jan 2013 07:55:53 +0000 (07:55 +0000)]
x86-64: Replace left over sti/cli in ia32 audit exit code

commit 40a1ef95da85843696fc3ebe5fce39b0db32669f upstream.

For some reason they didn't get replaced so far by their
paravirt equivalents, resulting in code to be run with
interrupts disabled that doesn't expect so (causing, in the
observed case, a BUG_ON() to trigger) when syscall auditing is

David (Cc-ed) came up with an identical fix, so likely this can
be taken to count as an ack from him.

Reported-by: Peter Moody <>
Signed-off-by: Jan Beulich <>
Cc: David Vrabel <>
Cc: Konrad Rzeszutek Wilk <>
Signed-off-by: Ingo Molnar <>
Cc: Konrad Rzeszutek Wilk <>
Cc: David Vrabel <>
Tested-by: Peter Moody <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: Calling object_unrefer() when creating fb failure
liu chuansheng [Thu, 31 Jan 2013 14:13:00 +0000 (22:13 +0800)]
drm/radeon: Calling object_unrefer() when creating fb failure

commit f2d68cf4daa4de97d400d94836b907e35228e54f upstream.

When kzalloc() failed in radeon_user_framebuffer_create(), need to
call object_unreference() to match the object_reference().

Signed-off-by: liu chuansheng <>
Signed-off-by: xueminsu <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: prevent crash in the ring space allocation
Alex Deucher [Wed, 30 Jan 2013 19:24:09 +0000 (14:24 -0500)]
drm/radeon: prevent crash in the ring space allocation

commit fd5d93a0015ce1a7db881382022b2fcdfdc61760 upstream.

If the requested number of DWs on the ring is larger than
the size of the ring itself, return an error.

In testing with large VM updates, we've seen crashes when we
try and allocate more space on the ring than the total size
of the ring without checking.

This prevents the crash but for large VM updates or bo moves
of very large buffers, we will need to break the transaction
down into multiple batches.  I have patches to use IBs for
the next kernel.

Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: protect against div by 0 in backend setup
Mikko Tiihonen [Wed, 30 Jan 2013 19:10:04 +0000 (14:10 -0500)]
drm/radeon: protect against div by 0 in backend setup

commit f689e3acbd2e48cc4101e0af454193f81af4baaf upstream.

Make sure at least one RB is enabled in
r6xx_remap_render_backend() to avoid an division by
zero in some corner cases.


Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: fix backend map setup on 1 RB sumo boards
Alex Deucher [Wed, 30 Jan 2013 18:57:40 +0000 (13:57 -0500)]
drm/radeon: fix backend map setup on 1 RB sumo boards

commit f7eb97300832f4fe5fe916c5d84cd2e25169330e upstream.

Need to adjust the backend map depending on which
RB is enabled.


Reported-by: Mikko Tiihonen <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: fix MC blackout on evergreen+
Christopher Staite [Sat, 26 Jan 2013 16:10:58 +0000 (11:10 -0500)]
drm/radeon: fix MC blackout on evergreen+

commit bb588820ef421c6098dca1fec29c3b347f1c8c19 upstream.

Force the crtc mem requests on/off immediately rather
than waiting for the double buffered updates to kick in.
Seems we miss the update in certain conditions.  Also
handle the DCE6 case.

Signed-off-by: Christopher Staite <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: add quirk for RV100 board
Alex Deucher [Tue, 29 Jan 2013 21:36:47 +0000 (16:36 -0500)]
drm/radeon: add quirk for RV100 board

commit 9200ee4941a6e5d1ec5df88982243686882dff3f upstream.

vbios says external TMDS while the board is actually
internal TMDS.


Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
5 years agodrm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
Alex Deucher [Mon, 28 Jan 2013 02:57:51 +0000 (21:57 -0500)]
drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN

commit 674a16f2b4724880d07389abbb95abf320b924aa upstream.

Newer versions of mesa emit this.

Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>