| Age | Commit message (Collapse) | Author |
|---|
|
sparse says:
drivers/net/wireless/atmel.c:1501:3: warning: Initializer entry defined twice
drivers/net/wireless/atmel.c:1505:3: also defined here
and it's correct; atmel has its own ndo_change_mtu and
shouldn't use eth_change_mtu.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
pcnet_cs: add cis(firmware) of the Allied Telesis LA-PCM
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If creating a workqueue fails, don't jump to the error path where that
same workqueue is destroyed, since destroy_workqueue() can't handle a
NULL pointer.
This was spotted by the Coverity checker (CID 2617).
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The per ring counters are implemented in SW. Now moving to have the total
counters as the sum of all rings. This way the numbers will always be consistent
and we no longer depend on HW buffer size limitations for those counters
that can be insufficient in some cases.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The former usage was to set the NETIF_F_HW_CSUM flag which is not used
in get_tx_csum. It caused Ethtool to show tx checksum as "on" even
though it was turned off in previous operation.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The low level driver always assumes this handler exists.
The lack of it could cause kernel panic
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The query whether the port is up or not should be done at
the execution of the restart task and not when it is queued.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In case of failure of either srq creation or page allocation,
the cleanup code handled the failed ring as well, and tried
to destroy resources that where not allocated.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
The recent NVRAM patches sanitized how the driver deals with NVRAM
data, but they failed to bring the SEEPROM interfaces inline with
the new strategy. This patch brings the SEEPROM interfaces up to date.
This patch also reverts commit 0d489ffb76de0fe804cf06a9d4d11fa7342d74b9
("tg3: fix big endian MAC address collection failure").
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Tested-by: Robin Holt <holt@sgi.com>
Tested-by: James Bottomley <james.bottomley@HansenPartnership.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch fixes a hang on resume when the filesystem is not
available and request_firmware blocks.
However, the device does not accept the firmware on resume.
and it will exit with:
> firmware part 1 upload failed (-71).
> device is in a bad state. please reconnect it!
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
swap mwl8k_remove and mwl8k_shutdown functions to allow
"rmmod mwl8k; modprobe mwl8k"
Signed-off-by: Joerg Albert <jal2@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch deactivates powersave in station mode.
It does not work correctly yet, so the code does more harm than good.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
"not" is not printed without a space after %pM
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
After suspend & resume the rt2x00 devices won't wakeup
anymore due to a broken register information setup.
The most important problem is the release of the EEPROM
buffer which is completely cleared and never read again
after the suspend.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after detaching.
Since the tun device is the persistent data structure here (when
requested by the user), it makes much more sense to have the wait
queue live there. There is no reason to have it in tfile at all
since the only time we can wait is if we have a tun attached.
In fact we already have a wait queue in tun_struct, so we might
as well use it.
Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The commit c70f182940f988448f3c12a209d18b1edc276e33 ("tun: Fix
races between tun_net_close and free_netdev") fixed a race where
an asynchronous deletion of a tun device can hose a poll(2) on
a tun fd attached to that device.
However, this came at the cost of moving the tun wait queue into
the tun file data structure. The problem with this is that it
imposes restrictions on when and where the tun device can access
the wait queue since the tun file may change at any time due to
detaching and reattaching.
In particular, now that we need to use the wait queue on the
receive path it becomes difficult to properly synchronise this
with the detachment of the tun device.
This patch solves the original race in a different way. Since
the race is only because the underlying memory gets freed, we
can prevent it simply by ensuring that we don't do that until
all tun descriptors ever attached to the device (even if they
have since be detached because they may still be sitting in poll)
have been closed.
This is done by using reference counting the attached tun file
descriptors. The refcount in tun->sk has been reappropriated
for this purpose since it was already being used for that, albeit
from the opposite angle.
Note that we no longer zero tfile->tun since tun_get will return
NULL anyway after the refcount on tfile hits zero. Instead it
represents whether this device has ever been attached to a device.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
EEH attempts to recover up 6 times.
The last attempt leaves all the ports and adapter down.hen
The driver is then unloaded, bringing the adapter down again
unconditionally. The unload will hang.
Check if the adapter is already down before trying to bring it down again.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Release vectors when a MSI-X allocation fails.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The fatal error task can be scheduled while processing an offload packet
in NAPI context when the connection handle is bogus. this can race
with the ports being brought down and the cxgb3 workqueue being flushed.
Stop napi processing before flushing the work queue.
The ULP drivers (iSCSI, iWARP) might also schedule a task on keventd_wk
while releasing a connection handle (cxgb3_offload.c::cxgb3_queue_tid_release()).
The driver however does not flush any work on keventd_wq while being unloaded.
This patch also fixes this.
Also call cancel_delayed_work_sync in place of the the deprecated
cancel_rearming_delayed_workqueue.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use the existing periodic task to handle link faults.
The link fault interrupt handler is also called in work queue context,
which is wrong and might cause potential deadlocks.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Check whether the underlying device provides a set of ethtool ops before
checking for individual handlers to avoid NULL pointer dereferences.
Reported-by: Art van Breemen <ard@telegraafnet.nl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
EPERM means that disconnect() is runnung. It should be treated like
ENODEV
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Suppose that we receive lots of frames, start processing them, but
exhaust our budget so that we return before we had a chance to look
at all of them.
Then, when the network layer calls us again, we will only continue
processing the buffers if the REC bit was set in the mean time, which it
might not be if there was a brief pause in the flow of packets. If this
happens, we'll simply display a warning and call netif_rx_complete()
with potentially lots of unprocessed packets in the RX ring...
Fix this by scanning the ring no matter what flags are set in the
interrupt status register.
Signed-off-by: Erik Waling <erik.waling@konftel.com>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When transfering large amounts of data we sometimes experienced that the
Retry Limit Exceeded (RLE) bit got set in TSR during transmission
attempts. When this happened the driver would stall in a state that
prevented any more data from being sent.
Signed-off-by: Erik Waling <erik.waling@konftel.com>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The thresholds for the DCB priority flow control are incorrect for 82599.
This fixes the thresholds to be correct.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The traffic classes in hardware are not symmetrical for Rx and Tx. Rx
is every 16 descriptor queues, Tx is not. It runs 32-32-16-16-8-8-8 when
running with 8 traffic classes, and runs 64-32-16 when running with 4
traffic classes. This patch fixes the mapping.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Cc: stable@kernel.org
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the e1000 transmit cleanup inner loop exited early, then
cleaned might not be true. This could cause tx hangs or other
badness. Use count to track the total number of descriptors
cleaned instead of basing a tx queue restart off of a temporary
working state variable.
This code now makes the flow the same for e1000/e1000e/igb/ixgbe
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the e1000e transmit cleanup inner loop exited early, then
cleaned might not be true. This could cause tx hangs or other
badness. Use count to track the total number of descriptors
cleaned instead of basing a tx queue restart off of a temporary
working state variable.
This code now makes the flow the same for e1000/e1000e/igb/ixgbe
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
GCC warns:
drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_sfp_config_module_task':
drivers/net/ixgbe/ixgbe_main.c:3920: warning: suggest parantheses around
operand of '!' or change '&' to '&&' or '!' to '~'
Which I think is right. Bracket to remove ambiguity.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
arm will pad even between u8's, so mark the structs/unions
packed. Fixes a build bug on arm due to BUILD_BUG_ON tests
in the code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If the value read from HERMES_RID_TXQUEUEEMPTY becomes 0 after exactly
100 readings, we wrongly consider it a timeout. Rewrite the clever
while loop as a for loop that does the right thing and looks simpler.
Reported by Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
In a scenario where there isn't any firmware available, we will have a
double kfree of rt2x00dev->spec.channels_info when ieee80211_register_hw
returns an error status inside rt2x00lib_probe_hw.
The problem is that if ieee80211_register_hw fails, we call
rt2x00lib_remove_hw twice:
* first inside rt2x00lib_probe_hw upon failure of ieee80211_register_hw
* error status is returned to rt2x00lib_probe_dev, which then sees it and
calls in this case rt2x00lib_remove_dev that will again run
rt2x00lib_remove_hw
Prevent this avoiding calling rt2x00lib_remove_hw inside
rt2x00lib_probe_hw
Problem was detected with CONFIG_DEBUG_PAGEALLOC=y, CONFIG_SLUB_DEBUG=y,
CONFIG_SLUB_DEBUG_ON=y, that dumps this with no firmware available:
rt61pci 0000:00:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
wmaster0 (rt61pci): not using net_device_ops yet
phy0: Selected rate control algorithm 'pid'
phy0: Failed to initialize wep: -2
phy0 -> rt2x00lib_probe_dev: Error - Failed to initialize hw.
=============================================================================
BUG kmalloc-128: Object already free
-----------------------------------------------------------------------------
INFO: Allocated in rt61pci_probe_hw+0x3e5/0x6e0 [rt61pci] age=340 cpu=0 pid=21
INFO: Freed in rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib] age=0 cpu=0 pid=21
INFO: Slab 0xc13ac3e0 objects=23 used=10 fp=0xdd59f6e0 flags=0x400000c3
INFO: Object 0xdd59f6e0 @offset=1760 fp=0xdd59f790
Bytes b4 0xdd59f6d0: 15 00 00 00 b2 8a fb ff 5a 5a 5a 5a 5a 5a 5a 5a ....².ûÿZZZZZZZZ
Object 0xdd59f6e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f6f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xdd59f750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk¥
Redzone 0xdd59f760: bb bb bb bb »»»»
Padding 0xdd59f788: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 21, comm: stage1 Not tainted 2.6.29.1-desktop-1.1mnb #1
Call Trace:
[<c01abbb3>] print_trailer+0xd3/0x120
[<c01abd37>] object_err+0x37/0x50
[<c01acf57>] __slab_free+0xe7/0x2f0
[<c01ad1de>] kfree+0x7e/0xd0
[<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
[<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
[<e0e4a239>] rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
[<e0e4acc7>] rt2x00lib_remove_dev+0x37/0x50 [rt2x00lib]
[<e0e4b087>] rt2x00lib_probe_dev+0x1a7/0x3b0 [rt2x00lib]
[<e0eb288f>] rt2x00pci_probe+0xdf/0x1ee [rt2x00pci]
[<c026b9ee>] local_pci_probe+0xe/0x10
[<c026c750>] pci_device_probe+0x60/0x80
[<c02d5c2a>] driver_probe_device+0x9a/0x2e0
[<c02d5ef9>] __driver_attach+0x89/0x90
[<c02d541b>] bus_for_each_dev+0x4b/0x70
[<c026c690>] ? pci_device_remove+0x0/0x40
[<c02d59d9>] driver_attach+0x19/0x20
[<c02d5e70>] ? __driver_attach+0x0/0x90
[<c02d4cef>] bus_add_driver+0x1cf/0x2a0
[<c026c690>] ? pci_device_remove+0x0/0x40
[<c02d60c9>] driver_register+0x69/0x140
[<c026c9b0>] __pci_register_driver+0x40/0x80
[<e0ecc000>] ? rt61pci_init+0x0/0x19 [rt61pci]
[<e0ecc017>] rt61pci_init+0x17/0x19 [rt61pci]
[<c0101116>] do_one_initcall+0x26/0x1c0
[<c01ab90c>] ? slab_pad_check+0x3c/0x120
[<c01ab90c>] ? slab_pad_check+0x3c/0x120
[<c01ac8da>] ? check_object+0xda/0x210
[<c01b0026>] ? percpu_free+0x46/0x50
[<c01ad09e>] ? __slab_free+0x22e/0x2f0
[<c01b0026>] ? percpu_free+0x46/0x50
[<c01b0026>] ? percpu_free+0x46/0x50
[<c01b0026>] ? percpu_free+0x46/0x50
[<c01687ec>] ? stop_machine_destroy+0x3c/0x40
[<c015e515>] ? load_module+0xa5/0x1c50
[<e0ec5000>] ? rt61pci_eepromregister_read+0x0/0x40 [rt61pci]
[<e0eb2000>] ? rt2x00pci_write_tx_data+0x0/0x90 [rt2x00pci]
[<c03ac2fb>] ? mutex_lock+0xb/0x20
[<c03ac2fb>] ? mutex_lock+0xb/0x20
[<c017ad16>] ? tracepoint_update_probe_range+0x76/0xa0
[<c017ad6f>] ? tracepoint_module_notify+0x2f/0x40
[<c03b02ed>] ? notifier_call_chain+0x2d/0x70
[<c014f0ed>] ? __blocking_notifier_call_chain+0x4d/0x60
[<c014f11a>] ? blocking_notifier_call_chain+0x1a/0x20
[<c0160156>] sys_init_module+0x96/0x1d0
[<c019dad6>] ? sys_munmap+0x46/0x60
[<c0105546>] syscall_call+0x7/0xb
FIX kmalloc-128: Object at 0xdd59f6e0 not freed
rt61pci 0000:00:07.0: PCI INT A disabled
rt61pci: probe of 0000:00:07.0 failed with error -2
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
I forgot that iwl3945 registration is separate from iwlagn.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The assertion of the lock-bit in the hardware register is unreliable,
because there are devices with quirks that will randomly set the bit.
Do the assertion in software, only.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch adds a new device to ar9170usb.
Reported-by: Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Code was clearly wrong, plus callers expect the mode change to happen as
soon as possible, not dropped on the floor until the next time some
other config value changes and a commit happens.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Add USB device ID for OQO 01+'s internal wireless LAN
An OQO employee mentions the chip's true identity here:-
ftp://ftp.oqo.com/unsupported/linux/OQOLinux.html
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Don't lead memory when receive errors
Signed-off-by: Philip Rakity <prakity@yahoo.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch fixes the bug that the driver tries to continue to
connect(associate) to AP even if gelic_wl_do_{wpa,wep}_setup() fails,
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch fixes the following waring:
> ------------[ cut here ]------------
>WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
>Modules linked in: p54spi
>[<c0034ff8>] (dump_stack+0x0/0x14)
>[<c005b1a4>] (warn_on_slowpath+0x0/0x68)
>[<c00604c8>] (local_bh_enable+0x0/0xbc)
>[<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi])
>[<c01a4d34>] (p54_sta_unlock+0x0/0x78)
p54spi_op_tx needs to be called from different locking contexts.
Therefore we have to protect the linked list with irqsave spinlocks.
Reported-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
I'm very sorry, as this change belongs to the other patch:
"[PATCH] p54: fix SoftLED compile dependencies".
however I must have somehow lost "git add" for that file.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
because it might be (partially) overwritten by some DMA operations.
Cc: stable@kernel.org
Cc: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch adds poisoning and sanity checking to the RX DMA buffers.
This is used for protection against buggy hardware/firmware that raises
RX interrupts without doing an actual DMA transfer.
This mechanism protects against rare "bad packets" (due to uninitialized skb data)
and rare kernel crashes due to uninitialized RX headers.
The poison is selected to not match on valid frames and to be cheap for checking.
The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
receiving frames with bad PLCP headers. However, this is nonfatal, because the
chance of such a match is basically zero and in case it happens it just results
in dropping the packet.
Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
to the latest news broadcasted by your microwave oven.
This patch also moves the initialization of the RX-header "length" field in front of
the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.
Cc: stable@kernel.org
Reported-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
