linux-toradex.git/drivers, branch v3.7.8

drm/nouveau: add lockdep annotations

2013-02-14T18:48:37+00:00

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

netback: correct netbk_tx_err to handle wrap around.

2013-02-14T18:48:29+00:00

[ Upstream commit b9149729ebdcfce63f853aa54a404c6a8f6ebbf3 ]

Signed-off-by: Ian Campbell 
Acked-by: Jan Beulich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen/netback: free already allocated memory on failure in xen_netbk_get_requests

2013-02-14T18:48:28+00:00

[ Upstream commit 4cc7c1cb7b11b6f3515bd9075527576a1eecc4aa ]

Signed-off-by: Ian Campbell 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.

2013-02-14T18:48:25+00:00

[ 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

xen/netback: shutdown the ring if it contains garbage.

2013-02-14T18:48:19+00:00

[ 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
penalised.

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
afterwards.

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

atm/iphase: rename fregt_t -> ffreg_t

2013-02-14T18:48:19+00:00

[ 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

via-rhine: Fix bugs in NAPI support.

2013-02-14T18:48:18+00:00

[ 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

net: loopback: fix a dst refcounting issue

2013-02-14T18:48:15+00:00

[ 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.

  [] loopback_xmit+0x64/0x83
  [] dev_hard_start_xmit+0x26c/0x35e
  [] dev_queue_xmit+0x2c4/0x37c
  [] ? dev_hard_start_xmit+0x35e/0x35e
  [] ? eth_header+0x28/0xb6
  [] neigh_resolve_output+0x176/0x1a7
  [] ip_finish_output2+0x297/0x30d
  [] ? ip_finish_output2+0x137/0x30d
  [] ip_finish_output+0x63/0x68
  [] ip_output+0x61/0x67
  [] dst_output+0x17/0x1b
  [] ip_local_out+0x1e/0x23
  [] ip_queue_xmit+0x315/0x353
  [] ? ip_send_unicast_reply+0x2cc/0x2cc
  [] tcp_transmit_skb+0x7ca/0x80b
  [] tcp_connect+0x53c/0x587
  [] ? getnstimeofday+0x44/0x7d
  [] ? ktime_get_real+0x11/0x3e
  [] tcp_v4_connect+0x3c2/0x431
  [] __inet_stream_connect+0x84/0x287
  [] ? inet_stream_connect+0x22/0x49
  [] ? _local_bh_enable_ip+0x84/0x9f
  [] ? local_bh_enable+0xd/0x11
  [] ? lock_sock_nested+0x6e/0x79
  [] ? inet_stream_connect+0x22/0x49
  [] inet_stream_connect+0x33/0x49
  [] 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
qdisc.

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

r8169: remove the obsolete and incorrect AMD workaround

2013-02-14T18:48:15+00:00

[ 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

netxen: fix off by one bug in netxen_release_tx_buffer()

2013-02-14T18:48:14+00:00

[ 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