* pull request: wireless-next-2.6 2010-12-08
From: John W. Linville @ 2010-12-08 21:04 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is the latest batch of updates intended for 2.6.38. It also
includes my last wireless-2.6 pull request that you just added
to net-2.6.
This includes the usual batch of drivers updates, with ath9k and
iwlwifi as the usual standouts. This also includes some mac80211
documentation updates from Johannes, and a flurry of ath5k updates
from Nick. This also includes a collection of bluetooth updates by
way of Gustavo, a couple of libertas updates, some more work on b43
N-phy support, and a variety of other patches.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit cfa969e385a23e4c85f50e0ed5de25a2e18bf9d4:
Revert "ehea: Use the standard logging functions" (2010-12-06 20:45:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Anderson Lizardo (1):
Bluetooth: Fix error handling for l2cap_init()
Andrei Emeltchenko (8):
Bluetooth: Check sk is not owned before freeing l2cap_conn
Bluetooth: timer check sk is not owned before freeing
Bluetooth: do not use assignment in if condition
Bluetooth: clean up sco code
Bluetooth: clean up rfcomm code
Bluetooth: clean up l2cap code
Bluetooth: clean up hci code
Bluetooth: clean up legal text
Andy Shevchenko (1):
wireless: ray_cs: use '%pm' format option to print MAC
Bala Shanmugam (1):
Bluetooth: Add new PID for Atheros 3011
Ben Greear (1):
ath9k: Move debugfs under ieee80211/[phyname]/ath9k/
Bruno Randolf (1):
cfg80211: Add documentation for antenna ops
Christian Lamparter (2):
carl9170: fix carl9170_tx_prepare typo
mac80211: ignore non-bcast mcast deauth/disassoc franes
Daniel Drake (1):
libertas: fix memory corruption in lbs_remove_card()
David Kilroy (1):
orinoco: abort scan on interface down
Felix Fietkau (12):
ath9k: fix software retry counter tracking
ath9k_hw: fix endian issues with CTLs on AR9003
ath9k_hw: fix more bitfield related endian issues
ath5k: Use Generic DMA for later support of AHB bus.
ath5k: Introduce ath5k_init_softc function as in ath9k
ath5k: Move PCI bus functions to separate file.
ath5k: Use generic eeprom read from common ath_bus_opts struct.
ath5k: Check if pci pdev struct is initialized in common functions.
ath5k: Add a function to read chipset's MAC revision
ath5k: Add initial registers values for radio RF2317 chip.
ath5k: Add AHB bus support.
ath5k: Fix reset and interrupts for AHB type of devices.
Gabor Juhos (1):
ath9k: use per-device struct for pm_qos_* operations
Gustavo F. Padovan (4):
Bluetooth: Fix not returning proper error in SCO
Merge git://git.kernel.org/.../padovan/bluetooth-2.6 into test
Bluetooth: Get rid of __l2cap_get_sock_by_psm()
Bluetooth: Get rid of __rfcomm_get_sock_by_channel()
Hauke Mehrtens (1):
ssb: Add sysfs attributes to ssb devices
Helmut Schaa (1):
mac80211: Minor optimization in ieee80211_rx_h_data
Joe Perches (2):
ath9k: hif_usb: Reduce indent 1 column
wireless: Remove unnecessary casts of usb_get_intfdata
Johan Hedberg (3):
Bluetooth: Simplify remote features callback function logic
Bluetooth: Create a unified authentication request function
Bluetooth: Automate remote name requests
Johannes Berg (17):
iwlagn: remove powersave warning
iwlagn: fix station powersave accounting for aggregation
iwlagn: advertise reliable TX status
iwlwifi: use mac80211 AC defines
ath9k/carl9170: advertise P2P
nl80211/cfg80211: extend mgmt-tx API for off-channel
mac80211: implement off-channel mgmt TX
mac80211: fix RX aggregation locking
cfg80211: include CQM packet loss docs
mac80211: document workqueue
mac80211: publish docs for _ni functions
mac80211: publish some misc docs
mac80211: publish some rate control docs
mac80211: document aggregation
mac80211: publish interface iteration docs
mac80211: document station handling
mac80211: publish SMPS docs
Johannes Stezenbach (1):
mac80211/rt2x00: add ieee80211_tx_status_ni()
John W. Linville (5):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-2.6
Revert "ath9k: Fix STA disconnect issue due to received MIC failed bcast frames"
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Jouni Malinen (1):
mac80211: Fix frame injection using non-AP vif
Mohammed Shafi Shajakhan (1):
ath9k: Add support for Adaptive Power Management
Nick Kossifidis (30):
ath5k: Reset cleanup and generic cleanup
ath5k: Add new function to stop rx/tx DMA
ath5k: Stop PCU on reset
ath5k: Use new dma_stop function on base.c
ath5k: Debug DMA timeouts
ath5k: Use DCU early termination correctly
ath5k: Check RXE when setting RXDP
ath5k: Use new function to stop beacon queue
ath5k: Add new field on ath5k_hw to track bandwidth modes
ath5k: Put core clock initialization on a new function
ath5k: Small cleanup on tweak_initvals
ath5k: Increase PHY settling parameters for turo mode
ath5k: Move tx retries setting outside reset_tx_queue
ath5k: Extend get_default_sifs/slot_time
ath5k: Extend rate_duration
ath5k: Set all IFS intervals, not just slot time
ath5k: Use turbo flag on DCU
ath5k: Always set IFS intervals on reset
ath5k: Tweak power detector delays on RF5111/RF5112
ath5k: Update spur mitigation filter for turbo/half/quarter
ath5k: Update PLL programming for turbo/half/quarter
ath5k: Skip powertable setting when we are on the same channel
ath5k: Support synth-only channel change for AR2413/AR5413
ath5k: No need to save/restore staid flags on reset
ath5k: Tweak phy activate to rx start delay based on bwmode
ath5k: Skip tx power setting on AR5210 for now
ath5k: Use correct clock when setting ofdm timings
ath5k: Cleanup turbo channel flags
ath5k: Clean up turbo mode initvals/rfregs
ath5k: Set turbo bit on rf bank 2
Rafał Miłecki (8):
ssb: extract indexes for power tables
b43: N-PHY: swap values for radio registers 0x3b and 0x3c
b43: N-PHY: implement very basic TX power control management
b43: N-PHY: initialize perical variable, add missing call to CCA reset
b43: N-PHY: fix RSSI calibration
b43: N-PHY: fix RSSI selection
b43: N-PHY: use defines for RSSI types
b43: N-PHY: fix code path on PHY init
Rajkumar Manoharan (2):
ath9k: Disable SWBA interrupt on remove_interface
Revert "ath9k_htc: Handle monitor mode properly for HTC devices"
Senthil Balasubramanian (2):
mac80211: Fix STA disconnect due to MIC failure
ath9k: Fix STA disconnect issue due to received MIC failed bcast frames
Stanislaw Gruszka (1):
iwlagn: fix microcode error on 4965
Stefan Seyfried (1):
Bluetooth: Fix log spamming in btusb due to autosuspend
Sujith Manoharan (1):
ath9k_htc: Remove unused structures
Sven Neumann (1):
libertas: fix invalid access
Vasanthakumar Thiagarajan (3):
ath9k: Reintroduce modparam to enable btcoex
ath9k: Remove code which enables btcoex based on subsys id
ath9k: Fix bug in reading input gpio state for ar9003
Vasiliy Kulikov (3):
Bluetooth: bnep: fix information leak to userland
Bluetooth: cmtp: fix information leak to userland
Bluetooth: hidp: fix information leak to userland
Wey-Yi Guy (8):
iwlwifi: remove unused define
iwlwifi: use antenna information in EEPROM
iwlagn: Offical name for 6050g2 device
iwlagn: Offical name for 6000g2a device
iwlagn: Offical name for 6000g2b device
iwlagn: Offical name for 100/130 device
iwlagn: use different kill mask when SCO active
iwlagn: minor change in bt coex normal LUT
Documentation/DocBook/80211.tmpl | 70 ++-
drivers/bluetooth/ath3k.c | 4 +
drivers/bluetooth/btusb.c | 12 +-
drivers/net/wireless/ath/ar9170/usb.c | 6 +-
drivers/net/wireless/ath/ath.h | 2 +
drivers/net/wireless/ath/ath5k/Kconfig | 17 +-
drivers/net/wireless/ath/ath5k/Makefile | 2 +
drivers/net/wireless/ath/ath5k/ahb.c | 219 +++++
drivers/net/wireless/ath/ath5k/ani.c | 6 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 260 ++++--
drivers/net/wireless/ath/ath5k/attach.c | 28 +-
drivers/net/wireless/ath/ath5k/base.c | 753 ++++++----------
drivers/net/wireless/ath/ath5k/base.h | 5 +-
drivers/net/wireless/ath/ath5k/caps.c | 6 -
drivers/net/wireless/ath/ath5k/debug.c | 1 +
drivers/net/wireless/ath/ath5k/debug.h | 2 +
drivers/net/wireless/ath/ath5k/desc.c | 24 +-
drivers/net/wireless/ath/ath5k/dma.c | 180 ++++-
drivers/net/wireless/ath/ath5k/eeprom.c | 127 ++--
drivers/net/wireless/ath/ath5k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath5k/initvals.c | 409 ++++----
drivers/net/wireless/ath/ath5k/led.c | 11 +-
drivers/net/wireless/ath/ath5k/pci.c | 326 +++++++
drivers/net/wireless/ath/ath5k/pcu.c | 571 ++++++++----
drivers/net/wireless/ath/ath5k/phy.c | 641 ++++++++++---
drivers/net/wireless/ath/ath5k/qcu.c | 692 ++++++++------
drivers/net/wireless/ath/ath5k/reg.h | 31 +-
drivers/net/wireless/ath/ath5k/reset.c | 1221 +++++++++++-------------
drivers/net/wireless/ath/ath5k/rfbuffer.h | 1169 ++++++++---------------
drivers/net/wireless/ath/ath5k/sysfs.c | 4 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 317 ++++---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 9 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 6 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 7 +-
drivers/net/wireless/ath/ath9k/beacon.c | 3 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 23 -
drivers/net/wireless/ath/ath9k/btcoex.h | 1 -
drivers/net/wireless/ath/ath9k/debug.c | 35 +-
drivers/net/wireless/ath/ath9k/debug.h | 16 -
drivers/net/wireless/ath/ath9k/eeprom.c | 6 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 28 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 11 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 119 ++--
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 64 ++-
drivers/net/wireless/ath/ath9k/htc_hst.h | 19 -
drivers/net/wireless/ath/ath9k/hw.c | 12 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 44 +-
drivers/net/wireless/ath/ath9k/main.c | 21 +-
drivers/net/wireless/ath/ath9k/reg.h | 6 +-
drivers/net/wireless/ath/ath9k/xmit.c | 27 +-
drivers/net/wireless/ath/carl9170/fw.c | 3 +-
drivers/net/wireless/ath/carl9170/main.c | 3 +-
drivers/net/wireless/ath/carl9170/tx.c | 2 +-
drivers/net/wireless/ath/carl9170/usb.c | 3 +-
drivers/net/wireless/b43/phy_n.c | 305 +++++--
drivers/net/wireless/b43/phy_n.h | 2 +-
drivers/net/wireless/b43/radio_2055.c | 246 +++---
drivers/net/wireless/iwlwifi/iwl-1000.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 66 +-
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 20 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 34 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 45 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 24 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 1 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 1 -
drivers/net/wireless/libertas/if_sdio.c | 1 -
drivers/net/wireless/libertas/if_spi.c | 1 -
drivers/net/wireless/libertas/main.c | 2 -
drivers/net/wireless/orinoco/main.c | 12 +-
drivers/net/wireless/orinoco/scan.c | 8 +
drivers/net/wireless/orinoco/scan.h | 1 +
drivers/net/wireless/p54/p54usb.c | 2 +-
drivers/net/wireless/ray_cs.c | 14 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 1 +
drivers/net/wireless/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 9 +-
drivers/net/wireless/zd1201.c | 2 +-
drivers/ssb/main.c | 30 +
drivers/ssb/pci.c | 44 +
include/linux/nl80211.h | 25 +-
include/linux/ssb/ssb.h | 4 +
include/linux/ssb/ssb_regs.h | 40 +
include/net/bluetooth/hci.h | 16 +-
include/net/bluetooth/hci_core.h | 14 +-
include/net/bluetooth/l2cap.h | 22 +-
include/net/bluetooth/rfcomm.h | 18 +-
include/net/bluetooth/sco.h | 20 +-
include/net/cfg80211.h | 18 +-
include/net/mac80211.h | 28 +-
net/bluetooth/bnep/core.c | 1 +
net/bluetooth/cmtp/core.c | 1 +
net/bluetooth/hci_conn.c | 23 +-
net/bluetooth/hci_core.c | 66 +-
net/bluetooth/hci_event.c | 177 +++-
net/bluetooth/hci_sock.c | 17 +-
net/bluetooth/hidp/core.c | 2 +-
net/bluetooth/l2cap.c | 94 ++-
net/bluetooth/rfcomm/core.c | 8 +-
net/bluetooth/rfcomm/sock.c | 24 +-
net/bluetooth/rfcomm/tty.c | 28 +-
net/bluetooth/sco.c | 28 +-
net/mac80211/agg-rx.c | 8 +-
net/mac80211/cfg.c | 94 ++-
net/mac80211/debugfs_sta.c | 29 +-
net/mac80211/ieee80211_i.h | 5 +
net/mac80211/rx.c | 28 +-
net/mac80211/sta_info.h | 29 +-
net/mac80211/status.c | 15 +-
net/mac80211/tx.c | 7 +-
net/mac80211/work.c | 22 +
net/wireless/core.h | 4 +-
net/wireless/mlme.c | 9 +-
net/wireless/nl80211.c | 57 +-
116 files changed, 5566 insertions(+), 3909 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/ahb.c
create mode 100644 drivers/net/wireless/ath/ath5k/pci.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-12-08.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* refcounting on dgram Unix sockets for poll(POLLOUT)
From: Alban Crequy @ 2010-12-08 21:01 UTC (permalink / raw)
To: netdev
Hi,
When a connected datagram Unix socket is polled for POLLOUT events, the
poller is added in the wait_queue_head_t of the "server" socket:
net/unix/af_unix.c::unix_dgram_poll()
other = unix_peer_get(sk);
if (other) {
if (unix_peer(other) != sk) {
sock_poll_wait(file, &unix_sk(other)->peer_wait,
wait);
...
I wonder what prevent the "server" socket ("other") to be released
while the poller is still waiting for POLLOUT events.
There is a reference taken on the "server" socket when the client
connects:
net/unix/af_unix.c::unix_dgram_connect()
other = unix_find_other(net, sunaddr, alen, sock->type,
hash, &err);
But that reference could be released when the client socket
disconnects from another thread in one of the 3 possible locations:
1. unix_dgram_connect() when connecting to a different socket
if (other != old_peer)
unix_dgram_disconnected(sk, old_peer);
sock_put(old_peer);
2. unix_dgram_sendmsg() when the server socket is SOCK_DEAD:
unix_dgram_disconnected(sk, other);
sock_put(other);
3. unix_release_sock() when the client socket is released:
skpair = unix_peer(sk);
if (skpair != NULL) {
sock_put(skpair); /* It may now die */
I tried to release all the references to server_sockfd with
close(server_sockfd) on the server thread and with
connect(client_sockfd) to a different socket while client_sockfd is
being polled for POLLOUT events in a different thread, hoping to crash
the poller with the stack:
free_poll_entry()->remove_wait_queue()->spin_lock_irqsave()
But I didn't manage to crash the kernel.
Am I missing something? Is there another reference taken on
server_sockfd to protect the kernel from this scenario?
And btw, what is the test (unix_peer(other) != sk) in unix_dgram_poll()?
Alban
^ permalink raw reply
* Re: [PATCH 1/2] via-velocity: set sleep speed to 10Mbps for powersaving.
From: David Miller @ 2010-12-08 20:56 UTC (permalink / raw)
To: davidlv.linux; +Cc: netdev, romieu, DavidLv, ShirleyHu, AndersMa
In-Reply-To: <AANLkTi==2E1VxbXatjEN7hORfPbxmiSTbD6SwqH5JGEu@mail.gmail.com>
From: David Lv <davidlv.linux@gmail.com>
Date: Wed, 8 Dec 2010 12:10:53 +0800
> I am sending this patch for setting speed to 10Mbps when entering into
> sleep mode.
> It is for power saving.
> Thanks!
>
> Signed-off-by: David Lv <DavidLv@viatech.com.cn>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
...
> + velocity_set_int_opt((int *) &opts->sleep_speed_10m, sleep_speed_10M[index],
> + SLEEP_SPEED_DISABLE, SLEEP_SPEED_ENABLE, SLEEP_SPEED_DEF, "Sleep
> Speed Forced 10M", devname);
...
Same problem here, you email client corrupted the patch,
please fix this and resubmit.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] via-velocity: fix the WOL bug on 1000M full duplex forced mode
From: David Miller @ 2010-12-08 20:56 UTC (permalink / raw)
To: davidlv.linux; +Cc: netdev, romieu, DavidLv, ShirleyHu, AndersMa
In-Reply-To: <AANLkTi=+r4cjE-3RJgrsrVaPBz0Ok_7XqZ+dxZgFCCUg@mail.gmail.com>
From: David Lv <davidlv.linux@gmail.com>
Date: Wed, 8 Dec 2010 13:47:19 +0800
> The VIA velocity card can't be waken up by WOL tool on 1000M full
> duplex forced mode.
> This patch fixes the bug.
> Thanks!
>
> Signed-off-by: David Lv <DavidLv@viatech.com.cn>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
...
>
> - MII_REG_BITS_OFF(ADVERTISE_1000FULL | ADVERTISE_1000HALF,
> MII_CTRL1000, vptr->mac_regs);
Your email client has corrupted the patch by chopping up long lines
etc., please correct this and resubmit your patch.
^ permalink raw reply
* Re: IPsecv6 tunnel mode fragmentation
From: David Miller @ 2010-12-08 20:37 UTC (permalink / raw)
To: herbert; +Cc: latten, netdev, samudrala, rashmin
In-Reply-To: <20101208071109.GA14537@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 8 Dec 2010 15:11:09 +0800
> Joy Latten <latten@austin.ibm.com> wrote:
>>
>> We have come across an ipsec problem that I think was
>> noted a while back in the following link.
>> http://www.mail-archive.com/netdev@vger.kernel.org/msg61659.html
>
> Looks like a configuration issue to me. One end is using the
> same IP address (*::1234) both within and outside the tunnel.
> Thus when the ICMP error message is sent it ends up outside the
> tunnel causing it to be discarded by the other side.
>
> So if you're using tunnel mode you really should use distinct
> IP addresses.
Agreed.
^ permalink raw reply
* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Paweł Staszewski @ 2010-12-08 20:30 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Paul Mackerras, bugzilla-daemon, bugme-daemon,
pstaszewski
In-Reply-To: <20101208122233.835a4997.akpm@linux-foundation.org>
W dniu 2010-12-08 21:22, Andrew Morton pisze:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 8 Dec 2010 20:14:45 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>>
>> Summary: Kernel panic - not syncing: Fatal Exception
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.36.1
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: pstaszewski@artcom.pl
>> Regression: No
>>
>>
>> Created an attachment (id=39332)
>> --> (https://bugzilla.kernel.org/attachment.cgi?id=39332)
>> Kernel Panic
>>
>> Hello i have problems with ppp driver and pppoe
>> I have random kernel panics
>>
>> In attached image is Call Trace from panic.
>>
>>
> ppp_unregister_channel() appears to be using a bad pointer.
> --
Yes.
I see kernel panics when connection is terminated - but this happend
randomly
Sometimes to reproduce i need to connect->disconnect 50 - 60 times
before kernel panic.
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH] tcp: protect sysctl_tcp_cookie_size reads
From: David Miller @ 2010-12-08 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: Martin, netdev, bhutchings, william.allen.simpson
In-Reply-To: <1291760447.5324.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 23:20:47 +0100
> Make sure sysctl_tcp_cookie_size is read once in
> tcp_cookie_size_check(), or we might return an illegal value to caller
> if sysctl_tcp_cookie_size is changed by another cpu.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: avoid a possible divide by zero
From: David Miller @ 2010-12-08 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, Martin, netdev
In-Reply-To: <1291759435.5324.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 23:03:55 +0100
> [PATCH v2] tcp: avoid a possible divide by zero
>
> sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
> tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
> reading sysctl_tcp_tso_win_divisor exactly once.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/3] bonding: add the debugfs interface to see RLB hash table
From: Jay Vosburgh @ 2010-12-08 20:33 UTC (permalink / raw)
To: Taku Izumi; +Cc: netdev@vger.kernel.org, eric.dumazet, shemminger
In-Reply-To: <4CF89A00.8030902@jp.fujitsu.com>
Taku Izumi <izumi.taku@jp.fujitsu.com> wrote:
>Hi Jay,
>
>Thank you for your quick review. I update my patchset according to your comment.
>But I didn't take measures against your concern about seq_file. If I come up with
>a good idea, I'll correct it.
>
>--
>This patchset provides the debugfs facility to the bonding driver and
>the interface to see RLB hashtable in it.
>
> *[PATCH 1/3] bonding: add the debugfs facility to the bonding driver
> *[PATCH 2/3] bonding: migrate some macros from bond_alb.c to bond_alb.h
> *[PATCH 3/3] bonding: add the debugfs interface to see RLB hash table
After applying your patches to net-next-2.6, I'm seeing the
following crash when executing "rmmod bonding":
BUG: unable to handle kernel paging request at 6b6b6b9f
IP: [<c0201f11>] debugfs_remove_recursive+0x1e/0x11a
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/net/bond0/flags
Modules linked in: bonding(-) ipv6 mperf microcode loop tg3 e1000 libphy sworks_agp agpgart edd ext3 mbcache jbd pata_serverworks mptspi mptscsih mptbase [last unloaded: speedstep_lib]
Pid: 5237, comm: rmmod Not tainted 2.6.37-rc1-cur+ #11 /eserver xSeries 335 -[8676GBX]-
EIP: 0060:[<c0201f11>] EFLAGS: 00010202 CPU: 2
EIP is at debugfs_remove_recursive+0x1e/0x11a
EAX: 6b6b6b6b EBX: f4d99480 ECX: 00000000 EDX: f3d5a5d4
ESI: f4d99950 EDI: f2d445b8 EBP: f4d03eb8 ESP: f4d03ea8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rmmod (pid: 5237, ti=f4d02000 task=f3d5a240 task.ti=f4d02000)
Stack:
f4d03ec0 f4d99480 f4d99950 f4d99000 f4d03ec0 f801dc05 f4d03ef4 f8015c5b
c0156ab6 f4d03ed8 c0134ff0 f4d9949c f4d03ee4 c037ec67 f4d99150 f4d03ef4
f4d99000 f4d03f20 f4d99000 f4d03f08 c030eafe f4d03f20 c0ce4140 f80233a4
Call Trace:
[<f801dc05>] ? bond_debug_unregister+0xe/0x10 [bonding]
[<f8015c5b>] ? bond_uninit+0x324/0x36d [bonding]
[<c0156ab6>] ? trace_hardirqs_on+0xb/0xd
[<c0134ff0>] ? local_bh_enable_ip+0x97/0xae
[<c037ec67>] ? _raw_spin_unlock_bh+0x2f/0x32
[<c030eafe>] ? rollback_registered_many+0x187/0x1fb
[<c030eb81>] ? unregister_netdevice_many+0xf/0x4d
[<c0318890>] ? __rtnl_link_unregister+0x56/0x8a
[<c0318f45>] ? rtnl_link_unregister+0x19/0x21
[<f801e32d>] ? bonding_exit+0x30/0x3c [bonding]
[<c0162ddc>] ? sys_delete_module+0x184/0x1dc
[<c01555fe>] ? put_lock_stats+0xd/0x22
[<c0155708>] ? lock_release_holdtime+0xf5/0xfa
[<c01a8fa3>] ? sys_munmap+0x39/0x3f
[<c037f098>] ? restore_all_notrace+0x0/0x18
[<c010294c>] ? sysenter_do_call+0x12/0x32
Code: fc ff 89 d8 e8 27 77 fc ff 5b 5e 5d c3 55 89 e5 57 89 c7 56 53 83 ec 04 85 c0 0f 84 01 01 00 00 8b 40 40 85 c0 0f 84 f6 00 00 00 <83> 78 34 00 0f 84 ec 00 00 00 8b 47 34 31 d2 89 fe 05 a4 00 00
EIP: [<c0201f11>] debugfs_remove_recursive+0x1e/0x11a SS:ESP 0068:f4d03ea8
CR2: 000000006b6b6b9f
---[ end trace e274f539dfd6ed30 ]---
This happens regardless of activity; e.g., "insmod bonding
mode=balance-alb" followed immediately by "rmmod bonding" generates the
above.
Any thoughts?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: ctnetlink loop
From: Holger Eitzenberger @ 2010-12-08 20:31 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20101208.095020.245408999.davem@davemloft.net>
Hi,
> Holger, this replay -EAGAIN loop in nfnetlink processing was added by
> Pablo to handle module loading properly, I think. So it might not be
> safe to just unilaterally remove it.
thanks for your reply!
Pablo, do we really need the replay loop really? I now have several
boxes with problems due to this replay. 'perf report' always gives me
something like:
18.88% ulogd [kernel]
[k] __nla_put
10.73% ulogd [kernel]
[k] nla_parse
8.72% ulogd [kernel]
[k] __nla_reserve
6.64% ulogd [kernel]
[k] nla_put
5.14% ulogd [kernel]
[k] validate_nla
5.03% ulogd [kernel]
[k] pskb_expand_head
4.92% ulogd [kernel]
[k] ctnetlink_fill_info [nf_conntrack_netlink]
3.07% ulogd [kernel]
[k] skb_put
3.03% ulogd [kernel]
[k] ctnetlink_dump_counters [nf_conntrack
And 'strace' shows me that ulogd is stuck in its 'select' call.
/holger
^ permalink raw reply
* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Andrew Morton @ 2010-12-08 20:22 UTC (permalink / raw)
To: netdev, Paul Mackerras; +Cc: bugzilla-daemon, bugme-daemon, pstaszewski
In-Reply-To: <bug-24472-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 8 Dec 2010 20:14:45 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>
> Summary: Kernel panic - not syncing: Fatal Exception
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: pstaszewski@artcom.pl
> Regression: No
>
>
> Created an attachment (id=39332)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=39332)
> Kernel Panic
>
> Hello i have problems with ppp driver and pppoe
> I have random kernel panics
>
> In attached image is Call Trace from panic.
>
>
ppp_unregister_channel() appears to be using a bad pointer.
^ permalink raw reply
* Re: WARNING at local_bh_enable while tcp_retransmit
From: Jarek Poplawski @ 2010-12-08 20:20 UTC (permalink / raw)
To: Ilya Loginov; +Cc: netdev, davem
In-Reply-To: <20101208123645.84091844.isloginov@gmail.com>
Ilya Loginov wrote:
> On Tue, 07 Dec 2010 21:56:19 +0100
> Jarek Poplawski <jarkao2@gmail.com> wrote:
>
>> Hi, isn't any of your drivers disabling irqs on this path?
>
> No. But we are in soft_irq because tcp_retransmit. So, may be,
> interrupts were really disabled.
Should be easy to check by copying this WARN_ON_ONCE from
kernel/softirq.c:143 local_bh_enable to the beginning of
your rioth_start_xmit.
Jarek P.
^ permalink raw reply
* Re: [PATCH] ehea: Fixing LRO configuration
From: David Miller @ 2010-12-08 20:19 UTC (permalink / raw)
To: leitao; +Cc: bhutchings, shemminger, netdev
In-Reply-To: <1291834280-30787-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Wed, 8 Dec 2010 16:51:20 -0200
> In order to set LRO on ehea, the user must set a module parameter, which
> is not the standard way to do so. This patch adds a way to set LRO using
> the ethtool tool.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied, thanks Breno.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: David Miller @ 2010-12-08 20:16 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <alpine.DEB.2.00.1012081139180.2652@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 8 Dec 2010 11:42:38 -0800 (PST)
> Rather than printing the message to the log, use a mib counter to keep
> track of the count of occurences of time wait bucket overflow. Reduces
> spam in logs.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH] atm: correct sysfs 'device' link creation and parent relationships
From: David Miller @ 2010-12-08 20:15 UTC (permalink / raw)
To: kay.sievers-tD+1rO4QERM
Cc: dcbw-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
duncan.sands-GANU6spQydw, linux-usb-u79uwXL29TY76Z2rM5mHXA,
chas-vT06rRrALxcmhCb6mdbn6A
In-Reply-To: <20101208.101121.71114237.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 08 Dec 2010 10:11:21 -0800 (PST)
> From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
> Date: Tue, 7 Dec 2010 08:35:53 +0100
>
>> On Sun, Dec 5, 2010 at 23:17, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> The ATM subsystem was incorrectly creating the 'device' link for ATM
>>> nodes in sysfs. This led to incorrect device/parent relationships
>>> exposed by sysfs and udev. Instead of rolling the 'device' link by hand
>>> in the generic ATM code, pass each ATM driver's bus device down to the
>>> sysfs code and let sysfs do this stuff correctly.
>>
>> Looks good to me.
>
> I've applied this to net-2.6, thanks Dan.
Actually I'm reverting, it breaks the build.
Did you even grep for "atm_dev_register()" after changning the number
of arguments, or were you depending upon build failures to guide you?
Please never do the latter, as it always leads to things like this.
drivers/atm/fore200e.c:2577:7: error: too few arguments to function 'atm_dev_register'
drivers/atm/iphase.c:3175:2: error: too few arguments to function 'atm_dev_register'
...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: Tom Herbert @ 2010-12-08 19:42 UTC (permalink / raw)
To: davem, netdev; +Cc: eric.dumazet
Rather than printing the message to the log, use a mib counter to keep
track of the count of occurences of time wait bucket overflow. Reduces
spam in logs.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_minisocks.c | 2 +-
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index ebb0c80..12b2b18 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -230,6 +230,7 @@ enum
LINUX_MIB_TCPMINTTLDROP, /* RFC 5082 */
LINUX_MIB_TCPDEFERACCEPTDROP,
LINUX_MIB_IPRPFILTER, /* IP Reverse Path Filter (rp_filter) */
+ LINUX_MIB_TCPTIMEWAITOVERFLOW, /* TCPTimeWaitOverflow */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 1b48eb1..b14ec7d 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -253,6 +253,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPMinTTLDrop", LINUX_MIB_TCPMINTTLDROP),
SNMP_MIB_ITEM("TCPDeferAcceptDrop", LINUX_MIB_TCPDEFERACCEPTDROP),
SNMP_MIB_ITEM("IPReversePathFilter", LINUX_MIB_IPRPFILTER),
+ SNMP_MIB_ITEM("TCPTimeWaitOverflow", LINUX_MIB_TCPTIMEWAITOVERFLOW),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 43cf901..a66735f 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -347,7 +347,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
* socket up. We've got bigger problems than
* non-graceful socket closings.
*/
- LIMIT_NETDEBUG(KERN_INFO "TCP: time wait bucket table overflow\n");
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPTIMEWAITOVERFLOW);
}
tcp_update_metrics(sk);
--
1.7.3.1
^ permalink raw reply related
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:39 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835681.2560.53.camel@bwh-desktop>
On Wed, 2010-12-08 at 19:14 +0000, Ben Hutchings wrote:
> On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > > The implementation of the -U
> > > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > > vlan_tag and user_def are not specified.
> > >
> >
> > Having said that, don't u think that it could be more user friendly to
> > extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> > user_def and drop the n-tuple interface at all?
>
> No, we can't remove userland interfaces.
Having said that, this particular interface is fairly broken...
$ cat test.c
#include <stddef.h>
#include <stdio.h>
#include <linux/ethtool.h>
int main(void)
{
printf("%zd\n", offsetof(struct ethtool_rx_flow_spec, ring_cookie));
return 0;
}
$ cc -m64 -Wall test.c
$ ./a.out
152
$ cc -m32 -Wall test.c
$ ./a.out
148
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 19:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835644.2560.52.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
>> Ben Hutchings wrote:
>>> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>>>> It's a bit worse than that. Currently one can only append filters, not
>>>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>>>> a new filter for the same index.
>>>>> It looks like drivers for devices that use TCAMs should implement the
>>>>> RXNFC interface instead.
>>>>>
>>>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>>>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>>>> the destination Rx queue for a stream specified by a filter/filters.
>>> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
>>> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>>>
>>>> The
>>>> semantics for a specification of the steam is also quite different. For
>>>> instance, how do u define a rule to drop all packets with source IP
>>>> address 192.168.10.200 by means of RXNFC?
>>> Something like this, I think:
>>>
>>> struct ethtool_rxnfc insert_rule = {
>>> .cmd = ETHTOOL_SRXCLSRLINS,
>>> .flow_type = IP_USER_SPEC,
>>> .fs = {
>>> .flow_type = IP_USER_SPEC,
>>> .h_u.usr_ip4_spec = {
>>> .ip4src = inet_aton("192.168.10.200"),
>>> .ip_ver = ETH_RX_NFC_IP4
>>> },
>>> .m_u.usr_ip4_spec = {
>>> .ip4dst = 0xffffffff,
>>> .l4_4_bytes = 0xffffffff,
>>> .tos = 0xff,
>>> .proto = 0xff
>>> },
>>> .ring_cookie = RX_CLS_FLOW_DISC,
>>> .location = 0,
>>> }
>>> };
>> I think the mask would be 0 for don't care fields and 1 for care, so
>>
>> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
>> .m_u.usr_ip4_spec.ip4dst = htonl(0)
>> etc
>
> That is definitely the opposite of what ixgbe and sfc do for
> ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
> niu does for ethtool_rx_flow_spec.
These are the values as our HW at least wants them. The care bits are 1 in
the mask. It's not a huge deal, the driver can complement the masks.
>
> [...]
>>>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>>>> last in general may override the decision made based on the hash result.
>>>> So, it sounds like applying rules of SRXNTUPLE should come before
>>>> applying the RSS logic and only if there was no match RSS should be
>>>> applied to that frame. Do I get it right?
>>> That's right.
>> It can be more involved than this. Our HW allows a rule to select a
>> different part of the RSS table so you get a filter hit and still do RSS
>> afterwards if you want. Current ethtool interfaces do not support this,
>> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> So does the rule specify an offset added to the output of the RSS hash
> and indirection table, or can it also select a different indirection
> table? Our current hardware also has a filter flag for the former
> behaviour... There are still plenty of bits to spare in 'action' and
> 'ring_cookie' so perhaps we could define a flag for this?
You can partition the indirection table and then a rule can specify that
matching packets should consult region X of the table. The hash value is
not altered, just the part of the overall table it indexes into.
>
> Ben.
>
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835453.24019.13.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > The implementation of the -U
> > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > vlan_tag and user_def are not specified.
> >
>
> Having said that, don't u think that it could be more user friendly to
> extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> user_def and drop the n-tuple interface at all?
No, we can't remove userland interfaces.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Dimitris Michailidis
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <4CFFD470.5090407@chelsio.com>
On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
> Ben Hutchings wrote:
> > On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> >>>> It's a bit worse than that. Currently one can only append filters, not
> >>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
> >>>> field. For devices that use TCAMs, where position matters, it's quite an
> >>>> obstacle. It also means one cannot modify an existing filter by specifying
> >>>> a new filter for the same index.
> >>> It looks like drivers for devices that use TCAMs should implement the
> >>> RXNFC interface instead.
> >>>
> >> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> >> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> >> the destination Rx queue for a stream specified by a filter/filters.
> >
> > By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> > ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> >
> >> The
> >> semantics for a specification of the steam is also quite different. For
> >> instance, how do u define a rule to drop all packets with source IP
> >> address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
>
> I think the mask would be 0 for don't care fields and 1 for care, so
>
> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
> .m_u.usr_ip4_spec.ip4dst = htonl(0)
> etc
That is definitely the opposite of what ixgbe and sfc do for
ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
niu does for ethtool_rx_flow_spec.
[...]
> >> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> >> last in general may override the decision made based on the hash result.
> >> So, it sounds like applying rules of SRXNTUPLE should come before
> >> applying the RSS logic and only if there was no match RSS should be
> >> applied to that frame. Do I get it right?
> >
> > That's right.
>
> It can be more involved than this. Our HW allows a rule to select a
> different part of the RSS table so you get a filter hit and still do RSS
> afterwards if you want. Current ethtool interfaces do not support this,
> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
So does the rule specify an offset added to the output of the RSS hash
and indirection table, or can it also select a different indirection
table? Our current hardware also has a filter flag for the former
behaviour... There are still plenty of bits to spare in 'action' and
'ring_cookie' so perhaps we could define a flag for this?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 19:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291834931.2560.42.camel@bwh-desktop>
> The implementation of the -U
> option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> vlan_tag and user_def are not specified.
>
Having said that, don't u think that it could be more user friendly to
extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
user_def and drop the n-tuple interface at all?
thanks,
vlad
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:02 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291833578.17102.69.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 20:39 +0200, Vladislav Zolotarov wrote:
> > > The
> > > semantics for a specification of the steam is also quite different. For
> > > instance, how do u define a rule to drop all packets with source IP
> > > address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
> >
>
> Aha. Ok. From the remarks in the upstream ethtool.h I see now that
> ethtool_rxnfc has quite wide configuration possibilities (including the
> above). I missed it before. ;)
>
> Ben, could u, pls., explain me then what's the difference between
> defining the rule as u wrote above on top of -N option (nfc) and
> defining the rule doing the same thing on top on -U (n-tuple) option and
> when I as a user should prefer one option to another? Are they expected
> to be implemented differently from FW/HW perspective?
The -N option modifies the hash function for all flows of a specific
type (using ETHTOOL_SRXFH) whereas the -U option steers a specific flow
or set of flows (using ETHTOOL_SRXNTUPLE). The implementation of the -U
option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
vlan_tag and user_def are not specified.
> thanks,
> vlad
>
> P.S. I see that ethtool.h from the 2.6.36 tree already has the
> ethtool_rxnfc that would allow such a filtering definition however from
> the man page of the 2.6.36 version of the ethtool package it's unclear
> what should be a command line for such a configuration. Is it supported
> with the current ethtool version or maybe I'm missing something in a man
> page?
It's not supported. Santwona Behera implemented the kernel side of this
but so far as I know he never sent any patches for ethtool.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 18:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291828940.2560.17.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>> It's a bit worse than that. Currently one can only append filters, not
>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>> a new filter for the same index.
>>> It looks like drivers for devices that use TCAMs should implement the
>>> RXNFC interface instead.
>>>
>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>> the destination Rx queue for a stream specified by a filter/filters.
>
> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>
>> The
>> semantics for a specification of the steam is also quite different. For
>> instance, how do u define a rule to drop all packets with source IP
>> address 192.168.10.200 by means of RXNFC?
>
> Something like this, I think:
>
> struct ethtool_rxnfc insert_rule = {
> .cmd = ETHTOOL_SRXCLSRLINS,
> .flow_type = IP_USER_SPEC,
> .fs = {
> .flow_type = IP_USER_SPEC,
> .h_u.usr_ip4_spec = {
> .ip4src = inet_aton("192.168.10.200"),
> .ip_ver = ETH_RX_NFC_IP4
> },
> .m_u.usr_ip4_spec = {
> .ip4dst = 0xffffffff,
> .l4_4_bytes = 0xffffffff,
> .tos = 0xff,
> .proto = 0xff
> },
> .ring_cookie = RX_CLS_FLOW_DISC,
> .location = 0,
> }
> };
I think the mask would be 0 for don't care fields and 1 for care, so
.m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
.m_u.usr_ip4_spec.ip4dst = htonl(0)
etc
There's a lot of overlap between SRXCLSRLINS and SRXNTUPLE and neither is a
superset. SRXCLSRLINS has the advantage of specifying position but
SRXNTUPLE includes vlan and a device-specific field that are handy.
Also for reporting rules GRXNTUPLE is more flexible than GRXCLSRULE as it
lets the driver specify the information it reports. In fact I've been
thinking of using SRXCLSRLINS and GRXNTUPLE for cxgb4 but haven't gotten
over the ugliness of that yet.
>
> [...]
>> I also agree with Dimitris: what we have here is an offload of some
>> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
>> not) if it's allowed to configure more than one rule for the same
>> protocol the ordering of filtering rules is important: for instance if u
>> change the order of applying the rules in the example below the result
>> of the filtering for the traffic with both VLAN 4 and destination port
>> 3000 will be different.
>
> Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
> specific types of matching. There is some control of precedence between
> different types of match, but that's all.
>
>> ethtool -U ethX flow-type tcp4 vlan 4 action 0
>> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>>
>> By the way it's also unclear from the ethtool man page if it's allowed
>> to configure more than one rule for the same protocol. If it's not then
>> the above example is void... ;)
>
> It's allowed, but precedence is unspecified.
>
>> However, if we want to define a proper
>> filtering interface I think we shouldn't restrict the driver
>> implementation from defining a set of rules for the same protocol,
>> allowing not to though.
>>
>> So, I think that attaching an index to each rule could be a good idea -
>> this would allow us both inserting rules at the desired positions in the
>> filtering rule table and editing the existing rules.
>
> This really sounds like the RXNFC interface.
>
>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>> last in general may override the decision made based on the hash result.
>> So, it sounds like applying rules of SRXNTUPLE should come before
>> applying the RSS logic and only if there was no match RSS should be
>> applied to that frame. Do I get it right?
>
> That's right.
It can be more involved than this. Our HW allows a rule to select a
different part of the RSS table so you get a filter hit and still do RSS
afterwards if you want. Current ethtool interfaces do not support this,
basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> Ben.
>
^ permalink raw reply
* Re: [PATCH] X.25: decrement netdev reference counts on unload
From: David Miller @ 2010-12-08 18:55 UTC (permalink / raw)
To: apollon; +Cc: netdev
In-Reply-To: <20101207194330.GA22608@noc.grnet.gr>
From: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Date: Tue, 7 Dec 2010 21:43:30 +0200
> x25 does not decrement the network device reference counts on module unload.
> Thus unregistering any pre-existing interface after unloading the x25 module
> hangs and results in
>
> unregister_netdevice: waiting for tap0 to become free. Usage count = 1
>
> This patch decrements the reference counts of all interfaces in x25_link_free,
> the way it is already done in x25_link_device_down for NETDEV_DOWN events.
>
> Signed-off-by: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] ehea: Fixing LRO configuration
From: leitao @ 2010-12-08 18:51 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, davem, netdev, Breno Leitao
In-Reply-To: <1291833849.2560.26.camel@bwh-desktop>
In order to set LRO on ehea, the user must set a module parameter, which
is not the standard way to do so. This patch adds a way to set LRO using
the ethtool tool.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 75b099c..1f37ee6 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -261,6 +261,13 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
}
+static int ehea_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO
+ | ETH_FLAG_TXVLAN
+ | ETH_FLAG_RXVLAN);
+}
+
const struct ethtool_ops ehea_ethtool_ops = {
.get_settings = ehea_get_settings,
.get_drvinfo = ehea_get_drvinfo,
@@ -273,6 +280,8 @@ const struct ethtool_ops ehea_ethtool_ops = {
.get_ethtool_stats = ehea_get_ethtool_stats,
.get_rx_csum = ehea_get_rx_csum,
.set_settings = ehea_set_settings,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ehea_set_flags,
.nway_reset = ehea_nway_reset, /* Restart autonegotiation */
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a84c389..c7132e8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -675,7 +675,7 @@ static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
int vlan_extracted = ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) &&
pr->port->vgrp);
- if (use_lro) {
+ if (skb->dev->features & NETIF_F_LRO) {
if (vlan_extracted)
lro_vlan_hwaccel_receive_skb(&pr->lro_mgr, skb,
pr->port->vgrp,
@@ -777,7 +777,7 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
cqe = ehea_poll_rq1(qp, &wqe_index);
}
- if (use_lro)
+ if (dev->features & NETIF_F_LRO)
lro_flush_all(&pr->lro_mgr);
pr->rx_packets += processed;
@@ -3265,6 +3265,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
+
+ if (use_lro)
+ dev->features |= NETIF_F_LRO;
INIT_WORK(&port->reset_task, ehea_reset_port);
--
1.7.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox