linux-stable.git/drivers/net, branch v3.9.4

ntb_netdev: remove from list on exit

2013-05-24T18:36:05+00:00

commit 904435cf76a9bdd5eb41b1c4e049d5a64f3a8400 upstream.

The ntb_netdev device is not removed from the global list of devices
upon device removal.  If the device is re-added, the removal code would
find the first instance and try to remove an already removed device.

Signed-off-by: Jon Mason 
Signed-off-by: Greg Kroah-Hartman

macvlan: fix passthru mode race between dev removal and rx path

2013-05-19T18:38:38+00:00

[ Upstream commit 233c7df0821c4190e2d3f4be0f2ca0ab40a5ed8c ]

Currently, if macvlan in passthru mode is created and data are rxed and
you remove this device, following panic happens:

NULL pointer dereference at 0000000000000198
IP: [] macvlan_handle_frame+0x153/0x1f7 [macvlan]

I'm using following script to trigger this:


I run this script while "ping -f" is running on another machine to send
packets to e1 rx.

Reason of the panic is that list_first_entry() is blindly called in
macvlan_handle_frame() even if the list was empty. vlan is set to
incorrect pointer which leads to the crash.

I'm fixing this by protecting port->vlans list by rcu and by preventing
from getting incorrect pointer in case the list is empty.

Introduced by: commit eb06acdc85585f2 "macvlan: Introduce 'passthru' mode to takeover the underlying device"

Signed-off-by: Jiri Pirko 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

3c59x: fix PCI resource management

2013-05-19T18:38:37+00:00

[ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ]

The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address.  Fix this by claiming/releasing all PCI
resources in the PCI driver's probe()/remove() methods instead and get rid of
'must_free_region' flag weirdness (why would Cardbus claim anything for us?).

Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

3c59x: fix freeing nonexistent resource on driver unload

2013-05-19T18:38:37+00:00

[ Upstream commit c81400be716aa4c76f6ebf339ba94358dbbf6da6 ]

When unloading the driver that drives an EISA board, a message similar to the
following one is displayed:

Trying to free nonexistent resource <0000000000013000-000000000001301f>

Then an user is unable to reload the driver because the resource it requested in
the previous load hasn't been freed. This happens most probably due to a typo in
vortex_eisa_remove() which calls release_region() with 'dev->base_addr'  instead
of 'edev->base_addr'...

Reported-by: Matthew Whitehead 
Tested-by: Matthew Whitehead 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

asix: fix BUG in receive path when lowering MTU

2013-05-19T18:38:36+00:00

[ Upstream commit c5060cec6ba27ad3f0e7facfdf05d2f18e3e3010 ]

There is bug in the receive path of the asix driver at the time a
packet is received larger than MTU size and DF bit set:

 BUG: unable to handle kernel paging request at 0000004000000001
 IP: [] skb_release_head_state+0x2d/0xd2
 ...
 Call Trace:
  
  [] ? skb_release_all+0x9/0x1e
  [] ? __kfree_skb+0x9/0x6f
  [] ? asix_rx_fixup_internal+0xff/0x1ae [asix]
  [] ? usbnet_bh+0x4f/0x226 [usbnet]
  ...

It is easily reproducable by setting an MTU of 512 e. g. and sending
something like

  ping -s 1472 -c 1 -M do $SELF

from another box.

And this is because the rx->ax_skb is freed on error, but rx->ax_skb
is not reset, and the size is not reset to zero in this case.

And since the skb is added again to the usbnet->done skb queue it is
accessing already freed memory, resulting in the BUG when freeing a
2nd time.  I therefore think the value 0x0000004000000001 show in the
trace is more or less random data.

Signed-off-by: Holger Eitzenberger 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA)

2013-05-19T18:38:34+00:00

[ Upstream commit 3b54912f9cd167641b91d4a697bd742f70e534fe ]

The venerable 3c509 driver only sets its device parent in one case, the ISAPnP one.
It does this with the SET_NETDEV_DEV function. It should register with the device
hierarchy in two additional cases: standard (non-PnP) ISA and EISA.

- Currently they appear here:
/sys/devices/virtual/net/eth0 (standard ISA)
/sys/devices/virtual/net/eth1 (EISA)

- Rather, they should instead be here:
/sys/devices/isa/3c509.0/net/eth0 (standard ISA)
/sys/devices/pci0000:00/0000:00:07.0/00:04/net/eth1 (EISA)

Tested on ISA and EISA boards.

Signed-off-by: Matthew Whitehead 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: tun: release the reference of tun device in tun_recvmsg

2013-05-19T18:38:33+00:00

[ Upstream commit 3811ae76bc84e5dc1a670ae10695f046b310bee1 ]

We forget to release the reference of tun device in tun_recvmsg.
bug introduced in commit 54f968d6efdbf7dec36faa44fc11f01b0e4d1990
(tuntap: move socket to tun_file)

Signed-off-by: Gao feng 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sfc: Fix naming of MTD partitions for FPGA bitfiles

2013-05-19T18:38:33+00:00

[ Upstream commit 89cc80a44b7c320e08599cb86f6aef0ead8986a1 ]

efx_mcdi_get_board_cfg() uses a buffer for the firmware response that
is only large enough to hold subtypes for the originally defined set
of NVRAM partitions.  Longer responses are truncated, and we may read
off the end of the buffer when copying out subtypes for additional
partitions.  In particular, this can result in the MTD partition for
an FPGA bitfile being named e.g. 'eth5 sfc_fpga:00' when it should be
'eth5 sfc_fpga:01'.  This means the firmware update tool (sfupdate)
can't tell which bitfile should be written to the partition.

Correct the response buffer size.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

iwl4965: workaround connection regression on passive channel

2013-05-19T18:38:29+00:00

commit dd9c46408fdc07098333655ff27edf8cac8d9fcf upstream.

Jake reported that since commit 1672c0e31917f49d31d30d79067103432bc20cc7
"mac80211: start auth/assoc timeout on frame status", he is unable to
connect to his AP, which is configured to use passive channel.

After switch to passive channel 4965 firmware drops any TX packet until
it receives beacon. Before commit 1672c0e3 we waited on channel and
retransmit packet after 200ms, that makes we receive beacon on the
meantime and association process succeed. New mac80211 behaviour cause
that any ASSOC frame fail immediately on iwl4965 and we can not
associate.

This patch restore old mac80211 behaviour for iwl4965, by removing
IEEE80211_HW_REPORTS_TX_ACK_STATUS feature. This feature will be
added again to iwl4965 driver, when different, more complex
workaround for this firmware issue, will be added to the driver.

Bisected-by: Jake Edge 
Reported-and-tested-by: Jake Edge 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

B43: Handle DMA RX descriptor underrun

2013-05-19T18:38:29+00:00

commit 73b82bf0bfbf58e6ff328d3726934370585f6e78 upstream.

Add handling of rx descriptor underflow. This fixes a fault that could
happen on slow machines, where data is received faster than the CPU can
handle. In such a case the device will use up all rx descriptors and
refuse to send any more data before confirming that it is ok. This
patch enables necessary interrupt to discover such a situation and will
handle them by dropping everything in the ring buffer.

Reviewed-by: Michael Buesch 
Signed-off-by: Thommy Jakobsson 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman