* Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
From: Herbert Xu @ 2007-12-16 3:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: miles.lane, linux-kernel, netdev, mingo, a.p.zijlstra
In-Reply-To: <20071215031341.66dc0d05.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>
> My suspicion is that you've hit bad breakage in networking and lockdep just
> isn't sufficiently robust to handle what it's being given.
>
> Can you suggest a way in which others can reproduce this?
I can reproduce this now. I suspect it's to do with the namespace
work. I'll let you know when I have digged further.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
From: Andy Gospodarek @ 2007-12-16 3:17 UTC (permalink / raw)
To: Herbert Xu; +Cc: olel, fubar, akpm, bugme-daemon, shemminger, davem, netdev
In-Reply-To: <E1J3jE4-0000FE-00@gondolin.me.apana.org.au>
On Dec 15, 2007 9:27 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> > I agree with you completely, Herbet, which is why I was surprised that
> > my first apparently did not resolve the issue. I felt it should
> > have....
>
> Did it change all occurrences of read_lock(&bond->lock) to
> read_lock_bh? If so I better look at the lockdep output again.
>
Not all of them in the bonding code, but all two of them in the small patch.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
From: Herbert Xu @ 2007-12-16 3:23 UTC (permalink / raw)
To: Andy Gospodarek
Cc: olel, fubar, akpm, bugme-daemon, shemminger, davem, netdev
In-Reply-To: <bdfc5d6e0712151917k4adeaa34q3f498950883697ab@mail.gmail.com>
On Sat, Dec 15, 2007 at 10:17:35PM -0500, Andy Gospodarek wrote:
>
> Not all of them in the bonding code, but all two of them in the small patch.
OK, we need to change all of the ones that may be called from
process context with BH on.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: Herbert Xu @ 2007-12-16 3:41 UTC (permalink / raw)
To: Mariusz Kozlowski; +Cc: akpm, jgarzik, linux-kernel, netdev, davem, den, xemul
In-Reply-To: <E1J3jqN-0000Jq-00@gondolin.me.apana.org.au>
On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
>
> I suspect namespace borkage. But just because you pin-pointed
> my patch I'll try to track it down :)
Surprise surprise. The namespace seq patch missed two spots in
AF_PACKET.
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
The seq_open_net patch changed the meaning of seq->private.
Unfortunately it missed two spots in AF_PACKET, which still
used the old way of dereferencing seq->private, thus causing
weird and wonderful crashes when reading /proc/net/packet.
This patch fixes them.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 485af56..43e49f4 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1878,7 +1878,7 @@ static void *packet_seq_start(struct seq_file *seq, loff_t *pos)
static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
- struct net *net = seq->private;
+ struct net *net = seq_file_net(seq);
++*pos;
return (v == SEQ_START_TOKEN)
? sk_head(&net->packet.sklist)
@@ -1887,7 +1887,7 @@ static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
static void packet_seq_stop(struct seq_file *seq, void *v)
{
- struct net *net = seq->private;
+ struct net *net = seq_file_net(seq);
read_unlock(&net->packet.sklist_lock);
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} -> {softirq-on-R} usage.
From: Andrew Morton @ 2007-12-16 4:30 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, netdev, Ingo Molnar, Peter Zijlstra
In-Reply-To: <a44ae5cd0712151255u25610059u946d975324ae128@mail.gmail.com>
On Sat, 15 Dec 2007 15:55:09 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> On Dec 15, 2007 3:13 PM, Miles Lane <miles.lane@gmail.com> wrote:
> >
> > On Dec 15, 2007 6:13 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> > >
> > > > On Dec 14, 2007 6:36 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > > On Fri, 14 Dec 2007 17:13:21 -0500
> > > > > "Miles Lane" <miles.lane@gmail.com> wrote:
> > > > >
> > > > >
> > > > > > Sorry Andrew, I don't know who to forward this problem to.
> > > > > >
> > > > > > I tried running: find /proc | xargs cat
> > > > > > and got this:
> > > > > >
> > > > > > =================================
> > > > > > [ INFO: inconsistent lock state ]
> > > > > > 2.6.24-rc5-mm1 #26
> > > > > > ---------------------------------
> > > > > > inconsistent {in-softirq-W} -> {softirq-on-R} usage.
> > > > > > cat/6944 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > > > > > BUG: unable to handle kernel paging request at virtual address 0f1eff0b
> > > > > > printing ip: c01fe64d *pde = 00000000
> > > > > > Oops: 0000 [#1] PREEMPT SMP
> > > > > > last sysfs file: /sys/block/sda/sda3/stat
> > > > > > Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> > > > > > cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> > > > > > dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> > > > > > cryptomgr crypto_algapi tifm_7xx1 tifm_core yenta_socket
> > > > > > rsrc_nonstatic pcmcia_core iwl3945 iTCO_wdt iTCO_vendor_support
> > > > > > watchdog_core watchdog_dev snd_hda_intel mac80211 snd_pcm_oss
> > > > > > snd_mixer_oss cfg80211 snd_pcm sky2 snd_seq_dummy snd_seq_oss
> > > > > > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> > > > > > snd_seq_device snd soundcore snd_page_alloc shpchp pci_hotplug
> > > > > > firewire_ohci firewire_core crc_itu_t ata_generic piix ide_core
> > > > > >
> > > > > > Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26)
> > > > > > EIP: 0060:[<c01fe64d>] EFLAGS: 00210097 CPU: 0
> > > > > > EIP is at strnlen+0x9/0x1c
> > > > > > EAX: 0f1eff0b EBX: 0f1eff0b ECX: 0f1eff0b EDX: fffffffe
> > > > > > ESI: c05b74f6 EDI: d6267d94 EBP: d6267cc8 ESP: d6267cc8
> > > > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > > > > Process cat (pid: 6944, ti=d6267000 task=d5a09000 task.ti=d6267000)
> > > > > > Stack: d6267cfc c01fdd22 00000400 c05b74f4 00000001 c05b78f4 00000000 ffffffff
> > > > > > ffffffff c048f503 00000400 d5a09000 00000002 d6267d0c c01fdf41 d6267d94
> > > > > > db68c04a d6267d74 c012ae81 d6267d94 00000028 c05b89f7 00200046 00000000
> > > > > > Call Trace:
> > > > > > [<c0108eb2>] show_trace_log_lvl+0x12/0x25
> > > > > > [<c0108f4f>] show_stack_log_lvl+0x8a/0x95
> > > > > > [<c0108fe4>] show_registers+0x8a/0x1bd
> > > > > > [<c010922f>] die+0x118/0x1dc
> > > > > > [<c03cf706>] do_page_fault+0x5a4/0x681
> > > > > > [<c03cdd72>] error_code+0x72/0x78
> > > > > > [<c01fdd22>] vsnprintf+0x277/0x40e
> > > > > > [<c01fdf41>] vscnprintf+0xe/0x1d
> > > > > > [<c012ae81>] vprintk+0xcb/0x2f3
> > > > > > [<c012b0be>] printk+0x15/0x17
> > > > > > [<c0145e55>] print_lock_name+0x4e/0xa2
> > > > > > [<c0146099>] print_lock+0xe/0x3a
> > > > > > [<c01464cf>] print_usage_bug+0xbc/0x117
> > > > > > [<c0146fb6>] mark_lock+0x2e7/0x3fe
> > > > > > [<c0147b9a>] __lock_acquire+0x498/0xbf4
> > > > > > [<c014836c>] lock_acquire+0x76/0x9d
> > > > > > [<c03cd6d2>] _read_lock+0x23/0x32
> > > > > > [<c03491ae>] sock_i_ino+0x14/0x30
> > > > > > [<c03c88ed>] packet_seq_show+0x22/0x75
> > > > > > [<c019b41a>] seq_read+0x19d/0x26f
> > > > > > [<c01b0ded>] proc_reg_read+0x60/0x74
> > > > > > [<c01854aa>] vfs_read+0x8a/0x106
> > > > > > [<c01858a8>] sys_read+0x3b/0x60
> > > > > > [<c0107cea>] sysenter_past_esp+0x6b/0xc1
> > > > > > =======================
> > > > > > Code: 01 00 00 00 4f 89 fa 5f 89 d0 5d c3 55 85 c9 89 e5 57 89 c7 89
> > > > > > d0 74 05 f2 ae 75 01 4f 89 f8 5f 5d c3 55 89 c1 89 e5 89 c8 eb 06 <80>
> > > > > > 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 5d c3 90 90 90 55 83
> > > > > > EIP: [<c01fe64d>] strnlen+0x9/0x1c SS:ESP 0068:d6267cc8
> > > > > > note: cat[6944] exited with preempt_count 4
> > > > >
> > > > > I'd say you hit a networking locking bug and then when trying to report
> > > > > that bug, lockdep crashed.
> > > > >
> > > > > The networking bug looks to be around sock_i_ino()'s taking of
> > > > > sk_callback_lock with softirq's enabled. Perhaps this will fix it.
> > > > >
> > > > > diff -puN net/core/sock.c~a net/core/sock.c
> > > > > --- a/net/core/sock.c~a
> > > > > +++ a/net/core/sock.c
> > > > > @@ -1115,9 +1115,9 @@ int sock_i_uid(struct sock *sk)
> > > > > {
> > > > > int uid;
> > > > >
> > > > > - read_lock(&sk->sk_callback_lock);
> > > > > + read_lock_bh(&sk->sk_callback_lock);
> > > > > uid = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_uid : 0;
> > > > > - read_unlock(&sk->sk_callback_lock);
> > > > > + read_unlock_bh(&sk->sk_callback_lock);
> > > > > return uid;
> > > > > }
> > > > >
> > > > > @@ -1125,9 +1125,9 @@ unsigned long sock_i_ino(struct sock *sk
> > > > > {
> > > > > unsigned long ino;
> > > > >
> > > > > - read_lock(&sk->sk_callback_lock);
> > > > > + read_lock_bh(&sk->sk_callback_lock);
> > > > > ino = sk->sk_socket ? SOCK_INODE(sk->sk_socket)->i_ino : 0;
> > > > > - read_unlock(&sk->sk_callback_lock);
> > > > > + read_unlock_bh(&sk->sk_callback_lock);
> > > > > return ino;
> > > > > }
> > > > >
> > > > > _
> > > > >
> > > > >
> > > >
> > > > I applied the patch and then tried my test again. This time my system
> > > > locked up.
> > > > Perhaps I should open a new thread for this, since the problem looks
> > > > pretty different.
> > > >
> > > > Dec 14 21:32:55 feargod kernel: process `cat' is using deprecated
> > > > sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
> > > > net.ipv6.neigh.default.retran
> > > > s_time_ms instead.
> > > > Dec 14 21:32:55 feargod kernel:
> > > > Dec 14 21:32:55 feargod kernel: =====================================
> > > > Dec 14 21:32:55 feargod kernel: [ BUG: bad unlock balance detected! ]
> > > > Dec 14 21:32:55 feargod kernel: -------------------------------------
> > > > Dec 14 21:32:55 feargod kernel: cat/6180 is trying to release lock
> > > > (kkkkkkk�����H3��) at:
> > > > Dec 14 21:32:55 feargod kernel: [packet_seq_stop+0xe/0x10]
> > > > packet_seq_stop+0xe/0x10
> > > > Dec 14 21:32:55 feargod kernel: but there are no more locks to release!
> > > > Dec 14 21:32:55 feargod kernel:
> > > > Dec 14 21:32:55 feargod kernel: other info that might help us debug this:
> > > > Dec 14 21:32:55 feargod kernel: 2 locks held by cat/6180:
> > > > Dec 14 21:32:55 feargod kernel: #0: (&p->lock){--..}, at:
> > > > [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
> > > > Dec 14 21:32:55 feargod kernel: #1:
> > > > (&net->packet.sklist_lock){-.--}, at: [packet_seq_start+0x14/0x4d]
> > > > packet_seq_start+0x14/0x4d
> > >
> > > Bit of a mess. We don't know whether lockdep is broken or if networking is
> > > just feeding it garbage. Or both.
> > >
> > > My suspicion is that you've hit bad breakage in networking and lockdep just
> > > isn't sufficiently robust to handle what it's being given.
> > >
> > > Can you suggest a way in which others can reproduce this?
> > >
> > > What happens if you run the same test with CONFIG_LOCKDEP=n?
> >
> > He's what I get with a build with CONFIG_LOCKDEP disabled (this is
> > 100% reproducible):
> >
> > process `head' is using deprecated sysctl (syscall)
> > net.ipv6.neigh.default.retrans_time; Use
> > net.ipv6.neigh.default.retrans
> > _time_ms instead.
> > BUG: unable to handle kernel paging request at virtual address 5a5a5b96
> > printing ip: c02024d5 *pde = 00000000
> > Oops: 0002 [#3] PREEMPT SMP
> > last sysfs file:
> > /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda3/stat
> > Modules linked in: aes_generic i915 drm rfcomm l2cap bluetooth
> > cpufreq_stats cpufreq_conservative cpufreq_performance sbs sbshc
> > dm_crypt sbp2 parport_pc lp parport pcmcia arc4 ecb crypto_blkcipher
> > cryptomgr crypto_algapi snd_hda_intel snd_pcm_oss snd_mixer_oss
> > snd_pcm tifm_7xx1 yenta_socket rsrc_nonstatic iwl3945 tifm_core
> > pcmcia_core snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi cfg80211
> > sky2 snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device
> > snd iTCO_wdt iTCO_vendor_support soundcore watchdog_core watchdog_dev
> > snd_page_alloc shpchp pci_hotplug ata_generic piix firewire_ohci
> > firewire_core crc_itu_t ide_core
> >
> > Pid: 6556, comm: head Tainted: G D (2.6.24-rc5-mm1 #29)
> > EIP: 0060:[<c02024d5>] EFLAGS: 00010013 CPU: 0
> > EIP is at _raw_read_trylock+0x3/0x19
Right. As I surmised, networking is passing garbage into lockdep and
lockdep didn't like it.
> > EAX: 5a5a5b96 EBX: 00000213 ECX: 00000001 EDX: ee062000
> > ESI: 5a5a5b96 EDI: ef182870 EBP: ee062ed0 ESP: ee062ed0
> > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > Process head (pid: 6556, ti=ee062000 task=ef262ba0 task.ti=ee062000)
> > Stack: ee062ee0 c03c746a 5a5a5a52 5a5a5b96 ee062eec c03c74f4 5a5a5a52 ee062efc
> > c0345f1e c03fd61c 5a5a5a52 ee062f10 c03c29e0 c03fd61c ef182870 5a5a5a52
> > ee062f50 c019448b 00002000 bff00b17 eefa4600 ef182890 00000000 00000000
> > Call Trace:
> > [<c0107daa>] show_trace_log_lvl+0x12/0x25
> > [<c0107e47>] show_stack_log_lvl+0x8a/0x95
> > [<c0107edc>] show_registers+0x8a/0x1bd
> > [<c0108127>] die+0x118/0x1dc
> > [<c03c92f0>] do_page_fault+0x589/0x666
> > [<c03c79ea>] error_code+0x72/0x78
> > [<c03c746a>] _read_lock_irqsave+0x2e/0x86
> > [<c03c74f4>] _read_lock_bh+0x9/0x1f
> > [<c0345f1e>] sock_i_ino+0x14/0x30
> > [<c03c29e0>] packet_seq_show+0x22/0x75
> > [<c019448b>] seq_read+0x192/0x25f
> > [<c01a9a95>] proc_reg_read+0x60/0x74
> > [<c017e8f6>] vfs_read+0x8a/0x106
> > [<c017ece0>] sys_read+0x3b/0x60
> > [<c0106cae>] sysenter_past_esp+0x6b/0xa1
> > =======================
> > Code: c2 89 e5 31 c0 86 02 31 c9 84 c0 0f 9f c1 85 c9 74 12 64 a1 08
> > a0 58 c0 89 42 0c 64 a1 00 a0 58 c0 89 42 10 5d 89 c8 c3 55 89 e5 <f0>
> > ff 08 83 38 00 ba 01 00 00 00 79 05 f0 ff 00 30 d2 5d 89 d0
> > EIP: [<c02024d5>] _raw_read_trylock+0x3/0x19 SS:ESP 0068:ee062ed0
> > note: head[6556] exited with preempt_count 2
>
> The command that reliably reproduces this is:
> cat /proc/net/packet
OK, thanks.
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-12-16 4:31 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
A few more fixes for 2.6.24...let me know if there are any problems!
Thanks,
John
P.S. The zd1211rw patch is already in netdev-2.6#upstream, but it
belongs in 2.6.24 as well.
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik
---
The following changes since commit 82d29bf6dc7317aeb0a3a13c2348ca8591965875:
Linus Torvalds (1):
Linux 2.6.24-rc5
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Adrian Bunk (1):
wireless/ipw2200.c: add __dev{init,exit} annotations
Andrew Morton (1):
bcm43xx_debugfs sscanf fix
Cyrill Gorcunov (2):
ieee80211_rate: missed unlock
iwlwifi3945/4965: fix rate control algo reference leak
Dan Williams (1):
libertas: select WIRELESS_EXT
Larry Finger (1):
b43: Fix rfkill radio LED
Stefano Brivio (1):
libertas: add Dan Williams as maintainer
Ulrich Kunitz (1):
zd1211rw: Fix alignment problems
Zhu Yi (1):
iwlwifi: fix rf_kill state inconsistent during suspend and resume
MAINTAINERS | 6 ++++
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/b43/leds.c | 4 ++
drivers/net/wireless/b43/main.c | 22 +++++++-------
drivers/net/wireless/b43/rfkill.c | 37 ++++++++++++++++++++---
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 2 +-
drivers/net/wireless/ipw2200.c | 7 ++--
drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 ++-
drivers/net/wireless/iwlwifi/iwl4965-base.c | 5 ++-
drivers/net/wireless/zd1211rw/zd_mac.c | 10 +++++-
net/mac80211/ieee80211_rate.c | 1 +
11 files changed, 76 insertions(+), 24 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9507b42..c331ba3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2489,6 +2489,12 @@ M: mtk.manpages@gmail.com
W: ftp://ftp.kernel.org/pub/linux/docs/manpages
S: Maintained
+MARVELL LIBERTAS WIRELESS DRIVER
+P: Dan Williams
+M: dcbw@redhat.com
+L: libertas-dev@lists.infradead.org
+S: Maintained
+
MARVELL MV643XX ETHERNET DRIVER
P: Dale Farnsworth
M: dale@farnsworth.org
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 2b733c5..5583719 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -264,6 +264,7 @@ config IPW2200_DEBUG
config LIBERTAS
tristate "Marvell 8xxx Libertas WLAN driver support"
depends on WLAN_80211
+ select WIRELESS_EXT
select IEEE80211
select FW_LOADER
---help---
diff --git a/drivers/net/wireless/b43/leds.c b/drivers/net/wireless/b43/leds.c
index 19e5885..6c0e2b9 100644
--- a/drivers/net/wireless/b43/leds.c
+++ b/drivers/net/wireless/b43/leds.c
@@ -163,6 +163,9 @@ static void b43_map_led(struct b43_wldev *dev,
b43_register_led(dev, &dev->led_radio, name,
b43_rfkill_led_name(dev),
led_index, activelow);
+ /* Sync the RF-kill LED state with the switch state. */
+ if (dev->radio_hw_enable)
+ b43_led_turn_on(dev, led_index, activelow);
break;
case B43_LED_WEIRD:
case B43_LED_ASSOC:
@@ -232,4 +235,5 @@ void b43_leds_exit(struct b43_wldev *dev)
b43_unregister_led(&dev->led_tx);
b43_unregister_led(&dev->led_rx);
b43_unregister_led(&dev->led_assoc);
+ b43_unregister_led(&dev->led_radio);
}
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index b45eecc..1c93b4f 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -2163,7 +2163,6 @@ static void b43_mgmtframe_txantenna(struct b43_wldev *dev, int antenna)
static void b43_chip_exit(struct b43_wldev *dev)
{
b43_radio_turn_off(dev, 1);
- b43_leds_exit(dev);
b43_gpio_cleanup(dev);
/* firmware is released later */
}
@@ -2191,11 +2190,10 @@ static int b43_chip_init(struct b43_wldev *dev)
err = b43_gpio_init(dev);
if (err)
goto out; /* firmware is released later */
- b43_leds_init(dev);
err = b43_upload_initvals(dev);
if (err)
- goto err_leds_exit;
+ goto err_gpio_clean;
b43_radio_turn_on(dev);
b43_write16(dev, 0x03E6, 0x0000);
@@ -2271,8 +2269,7 @@ out:
err_radio_off:
b43_radio_turn_off(dev, 1);
-err_leds_exit:
- b43_leds_exit(dev);
+err_gpio_clean:
b43_gpio_cleanup(dev);
return err;
}
@@ -3273,10 +3270,7 @@ static void b43_wireless_core_exit(struct b43_wldev *dev)
return;
b43_set_status(dev, B43_STAT_UNINIT);
- mutex_unlock(&dev->wl->mutex);
- b43_rfkill_exit(dev);
- mutex_lock(&dev->wl->mutex);
-
+ b43_leds_exit(dev);
b43_rng_exit(dev->wl);
b43_pio_free(dev);
b43_dma_free(dev);
@@ -3405,12 +3399,12 @@ static int b43_wireless_core_init(struct b43_wldev *dev)
memset(wl->mac_addr, 0, ETH_ALEN);
b43_upload_card_macaddress(dev);
b43_security_init(dev);
- b43_rfkill_init(dev);
b43_rng_init(wl);
b43_set_status(dev, B43_STAT_INITIALIZED);
- out:
+ b43_leds_init(dev);
+out:
return err;
err_chip_exit:
@@ -3499,6 +3493,10 @@ static int b43_start(struct ieee80211_hw *hw)
int did_init = 0;
int err = 0;
+ /* First register RFkill.
+ * LEDs that are registered later depend on it. */
+ b43_rfkill_init(dev);
+
mutex_lock(&wl->mutex);
if (b43_status(dev) < B43_STAT_INITIALIZED) {
@@ -3528,6 +3526,8 @@ static void b43_stop(struct ieee80211_hw *hw)
struct b43_wl *wl = hw_to_b43_wl(hw);
struct b43_wldev *dev = wl->current_dev;
+ b43_rfkill_exit(dev);
+
mutex_lock(&wl->mutex);
if (b43_status(dev) >= B43_STAT_STARTED)
b43_wireless_core_stop(dev);
diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
index 9b1f905..98cf70c 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -25,6 +25,8 @@
#include "rfkill.h"
#include "b43.h"
+#include <linux/kmod.h>
+
/* Returns TRUE, if the radio is enabled in hardware. */
static bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
@@ -50,7 +52,10 @@ static void b43_rfkill_poll(struct input_polled_dev *poll_dev)
bool report_change = 0;
mutex_lock(&wl->mutex);
- B43_WARN_ON(b43_status(dev) < B43_STAT_INITIALIZED);
+ if (unlikely(b43_status(dev) < B43_STAT_INITIALIZED)) {
+ mutex_unlock(&wl->mutex);
+ return;
+ }
enabled = b43_is_hw_radio_enabled(dev);
if (unlikely(enabled != dev->radio_hw_enable)) {
dev->radio_hw_enable = enabled;
@@ -60,8 +65,12 @@ static void b43_rfkill_poll(struct input_polled_dev *poll_dev)
}
mutex_unlock(&wl->mutex);
- if (unlikely(report_change))
- input_report_key(poll_dev->input, KEY_WLAN, enabled);
+ /* send the radio switch event to the system - note both a key press
+ * and a release are required */
+ if (unlikely(report_change)) {
+ input_report_key(poll_dev->input, KEY_WLAN, 1);
+ input_report_key(poll_dev->input, KEY_WLAN, 0);
+ }
}
/* Called when the RFKILL toggled in software. */
@@ -69,13 +78,15 @@ static int b43_rfkill_soft_toggle(void *data, enum rfkill_state state)
{
struct b43_wldev *dev = data;
struct b43_wl *wl = dev->wl;
- int err = 0;
+ int err = -EBUSY;
if (!wl->rfkill.registered)
return 0;
mutex_lock(&wl->mutex);
- B43_WARN_ON(b43_status(dev) < B43_STAT_INITIALIZED);
+ if (b43_status(dev) < B43_STAT_INITIALIZED)
+ goto out_unlock;
+ err = 0;
switch (state) {
case RFKILL_STATE_ON:
if (!dev->radio_hw_enable) {
@@ -133,9 +144,25 @@ void b43_rfkill_init(struct b43_wldev *dev)
rfk->poll_dev->poll = b43_rfkill_poll;
rfk->poll_dev->poll_interval = 1000; /* msecs */
+ rfk->poll_dev->input->name = rfk->name;
+ rfk->poll_dev->input->id.bustype = BUS_HOST;
+ rfk->poll_dev->input->id.vendor = dev->dev->bus->boardinfo.vendor;
+ rfk->poll_dev->input->evbit[0] = BIT(EV_KEY);
+ set_bit(KEY_WLAN, rfk->poll_dev->input->keybit);
+
err = rfkill_register(rfk->rfkill);
if (err)
goto err_free_polldev;
+
+#ifdef CONFIG_RFKILL_INPUT_MODULE
+ /* B43 RF-kill isn't useful without the rfkill-input subsystem.
+ * Try to load the module. */
+ err = request_module("rfkill-input");
+ if (err)
+ b43warn(wl, "Failed to load the rfkill-input module. "
+ "The built-in radio LED will not work.\n");
+#endif /* CONFIG_RFKILL_INPUT */
+
err = input_register_polled_device(rfk->poll_dev);
if (err)
goto err_unreg_rfk;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c b/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
index 35dbe45..76e9dd8 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -219,7 +219,7 @@ static ssize_t tsf_write_file(struct file *file, const char __user *user_buf,
ssize_t buf_size;
ssize_t res;
unsigned long flags;
- u64 tsf;
+ unsigned long long tsf;
buf_size = min(count, sizeof (really_big_buffer) - 1);
down(&big_buffer_sem);
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 54f44e5..da51f47 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -10751,7 +10751,7 @@ static void ipw_bg_link_down(struct work_struct *work)
mutex_unlock(&priv->mutex);
}
-static int ipw_setup_deferred_work(struct ipw_priv *priv)
+static int __devinit ipw_setup_deferred_work(struct ipw_priv *priv)
{
int ret = 0;
@@ -11600,7 +11600,8 @@ static void ipw_prom_free(struct ipw_priv *priv)
#endif
-static int ipw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int __devinit ipw_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
{
int err = 0;
struct net_device *net_dev;
@@ -11767,7 +11768,7 @@ static int ipw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
return err;
}
-static void ipw_pci_remove(struct pci_dev *pdev)
+static void __devexit ipw_pci_remove(struct pci_dev *pdev)
{
struct ipw_priv *priv = pci_get_drvdata(pdev);
struct list_head *p, *q;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4bdf237..8797233 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4743,8 +4743,10 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
* when we loaded driver, and is now set to "enable".
* After we're Alive, RF_KILL gets handled by
* iwl_rx_card_state_notif() */
- if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
+ if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
+ clear_bit(STATUS_RF_KILL_HW, &priv->status);
queue_work(priv->workqueue, &priv->restart);
+ }
handled |= CSR_INT_BIT_RF_KILL;
}
@@ -6171,6 +6173,7 @@ static void iwl_alive_start(struct iwl_priv *priv)
mutex_lock(&priv->mutex);
if (rc) {
+ iwl3945_rate_control_unregister(priv->hw);
IWL_ERROR("Failed to register network "
"device (error %d)\n", rc);
return;
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index 8f85564..d7cc514 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -5059,8 +5059,10 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
* when we loaded driver, and is now set to "enable".
* After we're Alive, RF_KILL gets handled by
* iwl_rx_card_state_notif() */
- if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status))
+ if (!hw_rf_kill && !test_bit(STATUS_ALIVE, &priv->status)) {
+ clear_bit(STATUS_RF_KILL_HW, &priv->status);
queue_work(priv->workqueue, &priv->restart);
+ }
handled |= CSR_INT_BIT_RF_KILL;
}
@@ -6527,6 +6529,7 @@ static void iwl_alive_start(struct iwl_priv *priv)
mutex_lock(&priv->mutex);
if (rc) {
+ iwl4965_rate_control_unregister(priv->hw);
IWL_ERROR("Failed to register network "
"device (error %d)\n", rc);
return;
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index a903645..5298a8b 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -1130,6 +1130,8 @@ static void zd_mac_rx(struct zd_mac *mac, struct sk_buff *skb)
__skb_trim(skb, skb->len -
(IEEE80211_FCS_LEN + sizeof(struct rx_status)));
+ ZD_ASSERT(IS_ALIGNED((unsigned long)skb->data, 4));
+
update_qual_rssi(mac, skb->data, skb->len, stats.signal,
status->signal_strength);
@@ -1166,15 +1168,19 @@ static void do_rx(unsigned long mac_ptr)
int zd_mac_rx_irq(struct zd_mac *mac, const u8 *buffer, unsigned int length)
{
struct sk_buff *skb;
+ unsigned int reserved =
+ ALIGN(max_t(unsigned int,
+ sizeof(struct zd_rt_hdr), ZD_PLCP_HEADER_SIZE), 4) -
+ ZD_PLCP_HEADER_SIZE;
- skb = dev_alloc_skb(sizeof(struct zd_rt_hdr) + length);
+ skb = dev_alloc_skb(reserved + length);
if (!skb) {
struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
dev_warn(zd_mac_dev(mac), "Could not allocate skb.\n");
ieee->stats.rx_dropped++;
return -ENOMEM;
}
- skb_reserve(skb, sizeof(struct zd_rt_hdr));
+ skb_reserve(skb, reserved);
memcpy(__skb_put(skb, length), buffer, length);
skb_queue_tail(&mac->rx_queue, skb);
tasklet_schedule(&mac->rx_tasklet);
diff --git a/net/mac80211/ieee80211_rate.c b/net/mac80211/ieee80211_rate.c
index 7254bd6..3260a4a 100644
--- a/net/mac80211/ieee80211_rate.c
+++ b/net/mac80211/ieee80211_rate.c
@@ -33,6 +33,7 @@ int ieee80211_rate_control_register(struct rate_control_ops *ops)
if (!strcmp(alg->ops->name, ops->name)) {
/* don't register an algorithm twice */
WARN_ON(1);
+ mutex_unlock(&rate_ctrl_mutex);
return -EALREADY;
}
}
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Please pull 'upstream-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-12-16 4:34 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 9005 bytes --]
Jeff,
Some more patches intended for 2.6.25... There are a bunch of libertas
patches in there, as well as some iwlwifi cleanups from the last merge
and a couple of b43 fixes resulting from a regression in an earlier
patch already queued in netdev-2.6#upstream.
Let me know if there are any problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik
---
The following changes since commit 9c8e86195d75a1f4875e9ced083a015a99cec94e:
John W. Linville (1):
rt2x00: correct "skb_buff" typo
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik ..BRANCH.NOT.VERIFIED..
Dan Williams (11):
orinoco: always use latest BSS info when caching scan results
libertas: make lbs_cmd() usage nicer
libertas: clean up is_command_allowed_in_ps()
libertas: clean up direct command handling
libertas: add simple copyback command callback
libertas: convert GET_HW_SPEC to a direct command
libertas: rename and re-type bufvirtualaddr to cmdbuf
libertas: fix case of FWT_ACCESS_LIST_ROUTE and FWT_ACCESS_LIST_NEIGHBOR commands
libertas: convert DATA_RATE to a direct command
libertas: convert RF_CHANNEL to a direct command
libertas: endianness fixes for get_channel/set_channel
David Woodhouse (76):
libertas: Fix memory leak of RX skbs
libertas: Remove cmd_oid from struct cmd_ctrl_node
libertas: Consolidate lbs_host_to_card_done() function.
libertas: Don't claim to have checksummed incoming packets.
libertas: Move SET_BOOT2_VER command to if_usb where it belongs
libertas: Zero 'pdata_size' field in cmd_ctrl_node reliably.
libertas: Byteswap cmdptr->size in lbs_cmd()
libertas: Use lbs_cmd() for setting Boot2 version
libertas: Remove SET_BOOT2_VER support from the Big Switch Statement.
libertas: Fix endianness in boot2_version handling.
libertas: when usb_submit_usb fails, include the error code in the printk
libertas: Switch to using a callback function pointer for commands
libertas: Don't set IW_ENCODE_NOKEY when returning WEP keys.
libertas: Fix up error handling in lbs_setuserscan()
libertas: kill adapter->nr_cmd_pending
libertas: switch lbs_cmd() to take a callback function pointer
libertas: clean up lbs_thread() to make it slightly more readable
libertas: fix lbs_rtap attribute in sysfs
libertas: kill TxLockFlag
libertas: kill struct lbs_adapter
libertas: use lbs_host_to_card_done() in lbs_tx_timeout()
libertas: cope with device which already has firmware loaded
libertas: stop debugfs code looking at cmdpendingq
libertas: kill internal tx queue for PS mode
libertas: kill SendSinglePacket() function.
libertas: move lbs_hard_start_xmit() into tx.c
libertas: kill lbs_process_tx() by merging it into lbs_hard_start_xmit()
libertas: clean up lbs_hard_start_xmit()
libertas: kill lbs_pre_start_xmit(), lib_mesh_pre_start_xmit()
libertas: stop using ieee80211 for radiotap device
libertas: set dev_addr on rtap device
libertas: TX packet is radiotap iff it comes from rtap_dev
libertas: free successfully transmitted skbs again
libertas: refactor the 'should I sleep?' decision in lbs_thread()
libertas: Move actual transmission to main thread
libertas: remove unreachable code from process_rxed_802_11_packet()
libertas: fix error cases in lbs_process_rxed_802_11_packet()
libertas: kill lbs_upload_tx_packet()
libertas: kill (IS,SET,UNSET)_MESH_FRAME.
libertas: add opaque extra argument to cmd callback function
libertas: clean up lbs_interrupt()
libertas: remove pre_open_check()
libertas: make rtap and normal modes mutually exclusive, clean up open/stop
libertas: improve reliability of firmware reloading on USB
libertas: switch to a waitqueue and timer for handling USB firmware load
libertas: don't run thread while firmware not yet ready
libertas: switch USB cardp->priv to 'struct lbs_private *' and resulting fix
libertas: move removal of lbs_rtap file to lbs_stop_card()
libertas: wait for 'firmware ready' event from firmware after loading
libertas: fix debug output in lbs_cmd_copyback() function.
libertas: convert CMD_MESH_ACCESS to a direct command
libertas: remove casts from lbs_cmd() and lbs_cmd_with_response() macros
libertas: make some more functions static
libertas: fix sparse endianness warnings in scan.c
libertas: add lbs_mesh sysfs attribute for enabling mesh
libertas: kill references to mesh autostart
libertas: kill rx_urb_recall and eth_dev members of struct usb_card_rec
libertas: whitespace cleanup in host.h
libertas: allow get/set SSID on mshX device
libertas: allow setting channel on mshX device
libertas: add missing newline on debug message
libertas: disable mesh temporarily while setting eth channel/assoc
libertas: add debugging output to lbs_mesh_config()
libertas: be more careful about command responses matching cur_cmd
libertas: add missing newlines in debugging statements
libertas: slight cleanup of netif queue stop/wake
libertas: add lbs_host_sleep_cfg() command function
libertas: switch lbs_cmd() to take a _pointer_ to the command structure
libertas: make worker thread not freezable
libertas: implement suspend and resume core methods
libertas: implement suspend/resume for USB devices
libertas: add ethtool support for wake-on-lan configuration
libertas: make lbs_update_channel() function non-static
libertas: cope with both old and new mesh TLV values
libertas: pass channel argument directly to lbs_mesh_config()
libertas: use spin_is_locked() instead of spin_trylock() in lbs_interrupt()
Holger Schurig (8):
libertas: remove cmd_ctrl_node->cmdflags
libertas: remove cmd_ctrl_node->status
libertas: make more functions static
libertas: handy function to call firmware commands
libertas: fix data packet size errors
libertas: implement new scanning logic
libertas: endianness fixes
libertas: fix use-after-free error
Li Zefan (1):
libertas: don't cast a pointer to pointer of
Michael Buesch (2):
b43: Fix ofdmtab write regression
b43: Fix for broken transmission
Reinette Chatre (1):
iwlwifi: remove HT code from iwl-3945.h
Tomas Winkler (2):
iwlwifi: fix compliation warnings
iwlwifi: add missing comments
drivers/net/wireless/b43/b43.h | 14 +-
drivers/net/wireless/b43/main.c | 12 +-
drivers/net/wireless/b43/phy.h | 6 +-
drivers/net/wireless/b43/tables.c | 35 +-
drivers/net/wireless/b43/wa.c | 30 +-
drivers/net/wireless/iwlwifi/iwl-3945.h | 24 -
drivers/net/wireless/iwlwifi/iwl-4965.h | 2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
drivers/net/wireless/iwlwifi/iwl4965-base.c | 6 +-
drivers/net/wireless/libertas/11d.c | 70 +-
drivers/net/wireless/libertas/assoc.c | 194 +++---
drivers/net/wireless/libertas/assoc.h | 2 +-
drivers/net/wireless/libertas/cmd.c | 899 +++++++++++++++---------
drivers/net/wireless/libertas/cmd.h | 40 +
drivers/net/wireless/libertas/cmdresp.c | 488 +++++--------
drivers/net/wireless/libertas/debugfs.c | 93 ++--
drivers/net/wireless/libertas/decl.h | 27 +-
drivers/net/wireless/libertas/defs.h | 15 +-
drivers/net/wireless/libertas/dev.h | 122 ++--
drivers/net/wireless/libertas/ethtool.c | 66 ++-
drivers/net/wireless/libertas/host.h | 386 +++++------
drivers/net/wireless/libertas/hostcmd.h | 74 ++-
drivers/net/wireless/libertas/if_cs.c | 43 +-
drivers/net/wireless/libertas/if_sdio.c | 37 +-
drivers/net/wireless/libertas/if_usb.c | 232 +++---
drivers/net/wireless/libertas/if_usb.h | 14 +-
drivers/net/wireless/libertas/join.c | 157 ++---
drivers/net/wireless/libertas/main.c | 995 ++++++++++++--------------
drivers/net/wireless/libertas/rx.c | 187 ++---
drivers/net/wireless/libertas/scan.c | 1048 ++++++++++++---------------
drivers/net/wireless/libertas/scan.h | 6 +-
drivers/net/wireless/libertas/tx.c | 240 +++----
drivers/net/wireless/libertas/wext.c | 496 +++++++------
drivers/net/wireless/orinoco.c | 11 +-
34 files changed, 3002 insertions(+), 3071 deletions(-)
create mode 100644 drivers/net/wireless/libertas/cmd.h
Omnibus patch attached as 'upstream-jgarzik.patch.bz2' due to size
constraints.
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream-jgarzik.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 65020 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] [UDP]: memory accounting and limitation (take 10)
From: David Miller @ 2007-12-16 5:34 UTC (permalink / raw)
To: haoki
Cc: herbert, netdev, tyasui, mhiramat, satoshi.oshima.fk, billfink,
andi, johnpol, shemminger, yoshfuji, yumiko.sugita.yf
In-Reply-To: <47636120.4050701@redhat.com>
From: Hideo AOKI <haoki@redhat.com>
Date: Sat, 15 Dec 2007 00:07:44 -0500
> Changelog take 9 -> take 10:
> * supported using sk_forward_alloc
> * introduced several memory accounting functions with spin lock
> * changed detagram receive functions to be able to customize
> destructor
> * fixed accounting bugs in previous takes
This is not what Herbert and I meant with our suggestion.
We meant to convert all of UDP and datagram handling to lock
sockets precisely like TCP does, by calling lock_sock()
on entry to functions like udp_recvmsg() and release_sock()
on exit from those functions.
Then in the packet input processing, a sequence, just like
TCP, such as:
bh_lock_sock_nested(sk);
if (!sock_owned_by_user(sk)) {
udp_do_rcv(sk, skb);
} else
sk_add_backlog(sk, skb);
Then a suitably defined ->backlog_rcv is hooked up for these
protocols as well.
Again, use TCP as a guide.
There is much more work involved to implement this properly,
and make the accounting code sharable with TCP, than the
simplistic and minimal spin lock code you added here.
Please do this correctly, thank you.
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: David Miller @ 2007-12-16 5:37 UTC (permalink / raw)
To: akpm; +Cc: herbert, netdev
In-Reply-To: <20071214214418.0ecd5e67.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 14 Dec 2007 21:44:18 -0800
> That sounds like a bug in mutex_trylock() to me.
I disagree, I have yet to see a legitimate case where doing a trylock
on a mutex lock didn't turn out to be a bug when performed in an
atomic context.
This is particularly true in the networking, the bonding driver
has provided some excellent examples over the years :-)
^ permalink raw reply
* Re: [NETFILTER] xt_hashlimit : speedups hash_dst()
From: David Miller @ 2007-12-16 5:42 UTC (permalink / raw)
To: dada1; +Cc: jarkao2, kaber, netfilter-devel, netdev
In-Reply-To: <4763B4CF.7010908@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Sat, 15 Dec 2007 12:04:47 +0100
> I prefer to let admins chose their size, since it makes attacker life more
> difficult :)
>
> For example, I can tell you I have a server, were size is between 2.000.000
> and 3.500.000, I dont want to be forced to use 2097152
>
> A multiply is cheap, at least on current hardware.
I agree, and I see nothing wrong with Eric's patch and it
should be merged ASAP.
^ permalink raw reply
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: David Miller @ 2007-12-16 5:44 UTC (permalink / raw)
To: herbert; +Cc: akpm, netdev, ebiederm
In-Reply-To: <20071215131016.GA28705@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 15 Dec 2007 21:10:16 +0800
> On Sat, Dec 15, 2007 at 02:48:10AM -0800, Andrew Morton wrote:
> >
> > Now as a separate issue we (ie: you) need to work out what _other_ things
> > you want ASSERT_RTNL to check apart from "rtnl must be held".
>
> Since we have now established that ASSERT_RTNL never actually
> warned about usage on paths with BH off, I think Eric's original
> patch is fine as it is and I owe him an apology.
Ok, same here...
Such situations (ASSERT_RTNL() in atomic context) have always
been bugs though, and that continues to be true and I think
the check should be added somehow.
^ permalink raw reply
* [PATCH] SCTP: Flush fragment queue when exiting partial delivery
From: Vlad Yasevich @ 2007-12-16 7:08 UTC (permalink / raw)
To: netdev; +Cc: lksctp-developers, Vlad Yasevich
At the end of partial delivery, we may have complete messages
sitting on the fragment queue. These messages are stuck there
until a new fragment arrives. This can comletely stall a
given association. When clearing partial delivery state, flush
any complete messages from the fragment queue and send them on
their way up.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/ulpqueue.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 4908041..1733fa2 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -53,6 +53,7 @@ static struct sctp_ulpevent * sctp_ulpq_reasm(struct sctp_ulpq *ulpq,
struct sctp_ulpevent *);
static struct sctp_ulpevent * sctp_ulpq_order(struct sctp_ulpq *,
struct sctp_ulpevent *);
+static void sctp_ulpq_reasm_drain(struct sctp_ulpq *ulpq);
/* 1st Level Abstractions */
@@ -190,6 +191,7 @@ static void sctp_ulpq_set_pd(struct sctp_ulpq *ulpq)
static int sctp_ulpq_clear_pd(struct sctp_ulpq *ulpq)
{
ulpq->pd_mode = 0;
+ sctp_ulpq_reasm_drain(ulpq);
return sctp_clear_pd(ulpq->asoc->base.sk, ulpq->asoc);
}
@@ -699,6 +701,37 @@ void sctp_ulpq_reasm_flushtsn(struct sctp_ulpq *ulpq, __u32 fwd_tsn)
}
}
+/*
+ * Drain the reassembly queue. If we just cleared parted delivery, it
+ * is possible that the reassembly queue will contain already reassembled
+ * messages. Retrieve any such messages and give them to the user.
+ */
+static void sctp_ulpq_reasm_drain(struct sctp_ulpq *ulpq)
+{
+ struct sctp_ulpevent *event = NULL;
+ struct sk_buff_head temp;
+
+ if (skb_queue_empty(&ulpq->reasm))
+ return;
+
+ while ((event = sctp_ulpq_retrieve_reassembled(ulpq)) != NULL) {
+ /* Do ordering if needed. */
+ if ((event) && (event->msg_flags & MSG_EOR)){
+ skb_queue_head_init(&temp);
+ __skb_queue_tail(&temp, sctp_event2skb(event));
+
+ event = sctp_ulpq_order(ulpq, event);
+ }
+
+ /* Send event to the ULP. 'event' is the
+ * sctp_ulpevent for very first SKB on the temp' list.
+ */
+ if (event)
+ sctp_ulpq_tail_event(ulpq, event);
+ }
+}
+
+
/* Helper function to gather skbs that have possibly become
* ordered by an an incoming chunk.
*/
--
1.5.3.5
^ permalink raw reply related
* [PATCH 2.6.25] SCTP: Use crc32c library for checksum calculations.
From: Vlad Yasevich @ 2007-12-16 7:10 UTC (permalink / raw)
To: netdev; +Cc: lksctp-developers, Vlad Yasevich
The crc32c library used an identical table and algorithm
as SCTP. Switch to using the library instead of carrying
our own table. Using crypto layer proved to have too
much overhead compared to using the library directly.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
include/net/sctp/checksum.h | 78 +++++++++++++++
include/net/sctp/sctp.h | 7 --
net/sctp/Kconfig | 1 +
net/sctp/Makefile | 2 +-
net/sctp/crc32c.c | 222 -------------------------------------------
net/sctp/input.c | 1 +
net/sctp/output.c | 1 +
7 files changed, 82 insertions(+), 230 deletions(-)
create mode 100644 include/net/sctp/checksum.h
delete mode 100644 net/sctp/crc32c.c
diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h
new file mode 100644
index 0000000..ba75c67
--- /dev/null
+++ b/include/net/sctp/checksum.h
@@ -0,0 +1,78 @@
+/* SCTP kernel reference Implementation
+ * Copyright (c) 1999-2001 Motorola, Inc.
+ * Copyright (c) 2001-2003 International Business Machines, Corp.
+ *
+ * This file is part of the SCTP kernel reference Implementation
+ *
+ * SCTP Checksum functions
+ *
+ * The SCTP reference implementation is free software;
+ * you can redistribute it and/or modify it under the terms of
+ * the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * The SCTP reference implementation is distributed in the hope that it
+ * will be useful, but WITHOUT ANY WARRANTY; without even the implied
+ * ************************
+ * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GNU CC; see the file COPYING. If not, write to
+ * the Free Software Foundation, 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ * Please send any bug reports or fixes you make to the
+ * email address(es):
+ * lksctp developers <lksctp-developers@lists.sourceforge.net>
+ *
+ * Or submit a bug report through the following website:
+ * http://www.sf.net/projects/lksctp
+ *
+ * Written or modified by:
+ * Dinakaran Joseph
+ * Jon Grimm <jgrimm@us.ibm.com>
+ * Sridhar Samudrala <sri@us.ibm.com>
+ *
+ * Rewritten to use libcrc32c by:
+ * Vlad Yasevich <vladislav.yasevich@hp.com>
+ *
+ * Any bugs reported given to us we will try to fix... any fixes shared will
+ * be incorporated into the next SCTP release.
+ */
+
+#include <linux/types.h>
+#include <net/sctp/sctp.h>
+#include <linux/crc32c.h>
+
+static inline __u32 sctp_start_cksum(__u8 *buffer, __u16 length)
+{
+ __u32 crc = ~(__u32) 0;
+ __u8 zero[sizeof(__u32)] = {0};
+
+ /* Optimize this routine to be SCTP specific, knowing how
+ * to skip the checksum field of the SCTP header.
+ */
+
+ /* Calculate CRC up to the checksum. */
+ crc = crc32c(crc, buffer, sizeof(struct sctphdr) - sizeof(__u32));
+
+ /* Skip checksum field of the header. */
+ crc = crc32c(crc, zero, sizeof(__u32));
+
+ /* Calculate the rest of the CRC. */
+ crc = crc32c(crc, &buffer[sizeof(struct sctphdr)],
+ length - sizeof(struct sctphdr));
+ return crc;
+}
+
+static inline __u32 sctp_update_cksum(__u8 *buffer, __u16 length, __u32 crc32)
+{
+ return crc32c(crc32, buffer, length);
+}
+
+static inline __u32 sctp_end_cksum(__u32 crc32)
+{
+ return ntohl(~crc32);
+}
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 34318a3..1b81ede 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -150,13 +150,6 @@ int sctp_primitive_REQUESTHEARTBEAT(struct sctp_association *, void *arg);
int sctp_primitive_ASCONF(struct sctp_association *, void *arg);
/*
- * sctp/crc32c.c
- */
-__u32 sctp_start_cksum(__u8 *ptr, __u16 count);
-__u32 sctp_update_cksum(__u8 *ptr, __u16 count, __u32 cksum);
-__u32 sctp_end_cksum(__u32 cksum);
-
-/*
* sctp/input.c
*/
int sctp_rcv(struct sk_buff *skb);
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index 5390bc7..0b79f86 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -10,6 +10,7 @@ menuconfig IP_SCTP
select CRYPTO_HMAC
select CRYPTO_SHA1
select CRYPTO_MD5 if SCTP_HMAC_MD5
+ select LIBCRC32C
---help---
Stream Control Transmission Protocol
diff --git a/net/sctp/Makefile b/net/sctp/Makefile
index 1da7204..f5356b9 100644
--- a/net/sctp/Makefile
+++ b/net/sctp/Makefile
@@ -9,7 +9,7 @@ sctp-y := sm_statetable.o sm_statefuns.o sm_sideeffect.o \
transport.o chunk.o sm_make_chunk.o ulpevent.o \
inqueue.o outqueue.o ulpqueue.o command.o \
tsnmap.o bind_addr.o socket.o primitive.o \
- output.o input.o debug.o ssnmap.o proc.o crc32c.o \
+ output.o input.o debug.o ssnmap.o proc.o \
auth.o
sctp-$(CONFIG_SCTP_DBG_OBJCNT) += objcnt.o
diff --git a/net/sctp/crc32c.c b/net/sctp/crc32c.c
deleted file mode 100644
index 181edab..0000000
--- a/net/sctp/crc32c.c
+++ /dev/null
@@ -1,222 +0,0 @@
-/* SCTP kernel reference Implementation
- * Copyright (c) 1999-2001 Motorola, Inc.
- * Copyright (c) 2001-2003 International Business Machines, Corp.
- *
- * This file is part of the SCTP kernel reference Implementation
- *
- * SCTP Checksum functions
- *
- * The SCTP reference implementation is free software;
- * you can redistribute it and/or modify it under the terms of
- * the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * The SCTP reference implementation is distributed in the hope that it
- * will be useful, but WITHOUT ANY WARRANTY; without even the implied
- * ************************
- * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- * See the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with GNU CC; see the file COPYING. If not, write to
- * the Free Software Foundation, 59 Temple Place - Suite 330,
- * Boston, MA 02111-1307, USA.
- *
- * Please send any bug reports or fixes you make to the
- * email address(es):
- * lksctp developers <lksctp-developers@lists.sourceforge.net>
- *
- * Or submit a bug report through the following website:
- * http://www.sf.net/projects/lksctp
- *
- * Written or modified by:
- * Dinakaran Joseph
- * Jon Grimm <jgrimm@us.ibm.com>
- * Sridhar Samudrala <sri@us.ibm.com>
- *
- * Any bugs reported given to us we will try to fix... any fixes shared will
- * be incorporated into the next SCTP release.
- */
-
-/* The following code has been taken directly from
- * draft-ietf-tsvwg-sctpcsum-03.txt
- *
- * The code has now been modified specifically for SCTP knowledge.
- */
-
-#include <linux/types.h>
-#include <net/sctp/sctp.h>
-
-#define CRC32C_POLY 0x1EDC6F41
-#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
-/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
-/* Copyright 2001, D. Otis. Use this program, code or tables */
-/* extracted from it, as desired without restriction. */
-/* */
-/* 32 Bit Reflected CRC table generation for SCTP. */
-/* To accommodate serial byte data being shifted out least */
-/* significant bit first, the table's 32 bit words are reflected */
-/* which flips both byte and bit MS and LS positions. The CRC */
-/* is calculated MS bits first from the perspective of the serial*/
-/* stream. The x^32 term is implied and the x^0 term may also */
-/* be shown as +1. The polynomial code used is 0x1EDC6F41. */
-/* Castagnoli93 */
-/* x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+ */
-/* x^11+x^10+x^9+x^8+x^6+x^0 */
-/* Guy Castagnoli Stefan Braeuer and Martin Herrman */
-/* "Optimization of Cyclic Redundancy-Check Codes */
-/* with 24 and 32 Parity Bits", */
-/* IEEE Transactions on Communications, Vol.41, No.6, June 1993 */
-/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
-static const __u32 crc_c[256] = {
- 0x00000000, 0xF26B8303, 0xE13B70F7, 0x1350F3F4,
- 0xC79A971F, 0x35F1141C, 0x26A1E7E8, 0xD4CA64EB,
- 0x8AD958CF, 0x78B2DBCC, 0x6BE22838, 0x9989AB3B,
- 0x4D43CFD0, 0xBF284CD3, 0xAC78BF27, 0x5E133C24,
- 0x105EC76F, 0xE235446C, 0xF165B798, 0x030E349B,
- 0xD7C45070, 0x25AFD373, 0x36FF2087, 0xC494A384,
- 0x9A879FA0, 0x68EC1CA3, 0x7BBCEF57, 0x89D76C54,
- 0x5D1D08BF, 0xAF768BBC, 0xBC267848, 0x4E4DFB4B,
- 0x20BD8EDE, 0xD2D60DDD, 0xC186FE29, 0x33ED7D2A,
- 0xE72719C1, 0x154C9AC2, 0x061C6936, 0xF477EA35,
- 0xAA64D611, 0x580F5512, 0x4B5FA6E6, 0xB93425E5,
- 0x6DFE410E, 0x9F95C20D, 0x8CC531F9, 0x7EAEB2FA,
- 0x30E349B1, 0xC288CAB2, 0xD1D83946, 0x23B3BA45,
- 0xF779DEAE, 0x05125DAD, 0x1642AE59, 0xE4292D5A,
- 0xBA3A117E, 0x4851927D, 0x5B016189, 0xA96AE28A,
- 0x7DA08661, 0x8FCB0562, 0x9C9BF696, 0x6EF07595,
- 0x417B1DBC, 0xB3109EBF, 0xA0406D4B, 0x522BEE48,
- 0x86E18AA3, 0x748A09A0, 0x67DAFA54, 0x95B17957,
- 0xCBA24573, 0x39C9C670, 0x2A993584, 0xD8F2B687,
- 0x0C38D26C, 0xFE53516F, 0xED03A29B, 0x1F682198,
- 0x5125DAD3, 0xA34E59D0, 0xB01EAA24, 0x42752927,
- 0x96BF4DCC, 0x64D4CECF, 0x77843D3B, 0x85EFBE38,
- 0xDBFC821C, 0x2997011F, 0x3AC7F2EB, 0xC8AC71E8,
- 0x1C661503, 0xEE0D9600, 0xFD5D65F4, 0x0F36E6F7,
- 0x61C69362, 0x93AD1061, 0x80FDE395, 0x72966096,
- 0xA65C047D, 0x5437877E, 0x4767748A, 0xB50CF789,
- 0xEB1FCBAD, 0x197448AE, 0x0A24BB5A, 0xF84F3859,
- 0x2C855CB2, 0xDEEEDFB1, 0xCDBE2C45, 0x3FD5AF46,
- 0x7198540D, 0x83F3D70E, 0x90A324FA, 0x62C8A7F9,
- 0xB602C312, 0x44694011, 0x5739B3E5, 0xA55230E6,
- 0xFB410CC2, 0x092A8FC1, 0x1A7A7C35, 0xE811FF36,
- 0x3CDB9BDD, 0xCEB018DE, 0xDDE0EB2A, 0x2F8B6829,
- 0x82F63B78, 0x709DB87B, 0x63CD4B8F, 0x91A6C88C,
- 0x456CAC67, 0xB7072F64, 0xA457DC90, 0x563C5F93,
- 0x082F63B7, 0xFA44E0B4, 0xE9141340, 0x1B7F9043,
- 0xCFB5F4A8, 0x3DDE77AB, 0x2E8E845F, 0xDCE5075C,
- 0x92A8FC17, 0x60C37F14, 0x73938CE0, 0x81F80FE3,
- 0x55326B08, 0xA759E80B, 0xB4091BFF, 0x466298FC,
- 0x1871A4D8, 0xEA1A27DB, 0xF94AD42F, 0x0B21572C,
- 0xDFEB33C7, 0x2D80B0C4, 0x3ED04330, 0xCCBBC033,
- 0xA24BB5A6, 0x502036A5, 0x4370C551, 0xB11B4652,
- 0x65D122B9, 0x97BAA1BA, 0x84EA524E, 0x7681D14D,
- 0x2892ED69, 0xDAF96E6A, 0xC9A99D9E, 0x3BC21E9D,
- 0xEF087A76, 0x1D63F975, 0x0E330A81, 0xFC588982,
- 0xB21572C9, 0x407EF1CA, 0x532E023E, 0xA145813D,
- 0x758FE5D6, 0x87E466D5, 0x94B49521, 0x66DF1622,
- 0x38CC2A06, 0xCAA7A905, 0xD9F75AF1, 0x2B9CD9F2,
- 0xFF56BD19, 0x0D3D3E1A, 0x1E6DCDEE, 0xEC064EED,
- 0xC38D26C4, 0x31E6A5C7, 0x22B65633, 0xD0DDD530,
- 0x0417B1DB, 0xF67C32D8, 0xE52CC12C, 0x1747422F,
- 0x49547E0B, 0xBB3FFD08, 0xA86F0EFC, 0x5A048DFF,
- 0x8ECEE914, 0x7CA56A17, 0x6FF599E3, 0x9D9E1AE0,
- 0xD3D3E1AB, 0x21B862A8, 0x32E8915C, 0xC083125F,
- 0x144976B4, 0xE622F5B7, 0xF5720643, 0x07198540,
- 0x590AB964, 0xAB613A67, 0xB831C993, 0x4A5A4A90,
- 0x9E902E7B, 0x6CFBAD78, 0x7FAB5E8C, 0x8DC0DD8F,
- 0xE330A81A, 0x115B2B19, 0x020BD8ED, 0xF0605BEE,
- 0x24AA3F05, 0xD6C1BC06, 0xC5914FF2, 0x37FACCF1,
- 0x69E9F0D5, 0x9B8273D6, 0x88D28022, 0x7AB90321,
- 0xAE7367CA, 0x5C18E4C9, 0x4F48173D, 0xBD23943E,
- 0xF36E6F75, 0x0105EC76, 0x12551F82, 0xE03E9C81,
- 0x34F4F86A, 0xC69F7B69, 0xD5CF889D, 0x27A40B9E,
- 0x79B737BA, 0x8BDCB4B9, 0x988C474D, 0x6AE7C44E,
- 0xBE2DA0A5, 0x4C4623A6, 0x5F16D052, 0xAD7D5351,
-};
-
-__u32 sctp_start_cksum(__u8 *buffer, __u16 length)
-{
- __u32 crc32 = ~(__u32) 0;
- __u32 i;
-
- /* Optimize this routine to be SCTP specific, knowing how
- * to skip the checksum field of the SCTP header.
- */
-
- /* Calculate CRC up to the checksum. */
- for (i = 0; i < (sizeof(struct sctphdr) - sizeof(__u32)); i++)
- CRC32C(crc32, buffer[i]);
-
- /* Skip checksum field of the header. */
- for (i = 0; i < sizeof(__u32); i++)
- CRC32C(crc32, 0);
-
- /* Calculate the rest of the CRC. */
- for (i = sizeof(struct sctphdr); i < length ; i++)
- CRC32C(crc32, buffer[i]);
-
- return crc32;
-}
-
-__u32 sctp_update_cksum(__u8 *buffer, __u16 length, __u32 crc32)
-{
- __u32 i;
-
- for (i = 0; i < length ; i++)
- CRC32C(crc32, buffer[i]);
-
- return crc32;
-}
-
-#if 0
-__u32 sctp_update_copy_cksum(__u8 *to, __u8 *from, __u16 length, __u32 crc32)
-{
- __u32 i;
- __u32 *_to = (__u32 *)to;
- __u32 *_from = (__u32 *)from;
-
- for (i = 0; i < (length/4); i++) {
- _to[i] = _from[i];
- CRC32C(crc32, from[i*4]);
- CRC32C(crc32, from[i*4+1]);
- CRC32C(crc32, from[i*4+2]);
- CRC32C(crc32, from[i*4+3]);
- }
-
- return crc32;
-}
-#endif /* 0 */
-
-__u32 sctp_end_cksum(__u32 crc32)
-{
- __u32 result;
- __u8 byte0, byte1, byte2, byte3;
-
- result = ~crc32;
-
- /* result now holds the negated polynomial remainder;
- * since the table and algorithm is "reflected" [williams95].
- * That is, result has the same value as if we mapped the message
- * to a polyomial, computed the host-bit-order polynomial
- * remainder, performed final negation, then did an end-for-end
- * bit-reversal.
- * Note that a 32-bit bit-reversal is identical to four inplace
- * 8-bit reversals followed by an end-for-end byteswap.
- * In other words, the bytes of each bit are in the right order,
- * but the bytes have been byteswapped. So we now do an explicit
- * byteswap. On a little-endian machine, this byteswap and
- * the final ntohl cancel out and could be elided.
- */
- byte0 = result & 0xff;
- byte1 = (result>>8) & 0xff;
- byte2 = (result>>16) & 0xff;
- byte3 = (result>>24) & 0xff;
-
- crc32 = ((byte0 << 24) |
- (byte1 << 16) |
- (byte2 << 8) |
- byte3);
- return crc32;
-}
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 91ae463..b08c7cb 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -60,6 +60,7 @@
#include <net/xfrm.h>
#include <net/sctp/sctp.h>
#include <net/sctp/sm.h>
+#include <net/sctp/checksum.h>
/* Forward declarations for internal helpers. */
static int sctp_rcv_ootb(struct sk_buff *);
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 847639d..5e811b9 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -60,6 +60,7 @@
#include <net/sctp/sctp.h>
#include <net/sctp/sm.h>
+#include <net/sctp/checksum.h>
/* Forward declarations for private helpers. */
static sctp_xmit_t sctp_packet_append_data(struct sctp_packet *packet,
--
1.5.3.5
^ permalink raw reply related
* Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Herbert Xu @ 2007-12-16 7:13 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, ebiederm
In-Reply-To: <20071215.214429.121871076.davem@davemloft.net>
On Sat, Dec 15, 2007 at 09:44:29PM -0800, David Miller wrote:
>
> Such situations (ASSERT_RTNL() in atomic context) have always
> been bugs though, and that continues to be true and I think
> the check should be added somehow.
OK once I've fixed the set_multicast path I'll do an audit of
the existing ASSERT_RTNL users and then add the might_sleep
check.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Openswan dev] ip xfrm bug
From: Herbert Xu @ 2007-12-16 7:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, netdev, jamal
In-Reply-To: <20071214112118.118862c3@deepthought>
On Fri, Dec 14, 2007 at 11:21:18AM -0800, Stephen Hemminger wrote:
>
> I can see where to filter these, but I am ignorant of how to
> identify the socket policies. Are they just marked as sub-policies?
Jamal's going to hate me but setkey(8) already uses this so we're
stuck with it anyway.
The test is
up->index % 8 >= 3
This is true iff it's a socket policy.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: Andrew Morton @ 2007-12-16 7:56 UTC (permalink / raw)
To: Miles Lane; +Cc: Herbert Xu, netdev, linux-kernel
In-Reply-To: <a44ae5cd0712152237y2f6a17fcu6a718757c7c021a3@mail.gmail.com>
On Sun, 16 Dec 2007 01:37:01 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
>
argh, please don't use linux-net. It's basically dead afaik.
Suitable ccs restored.
> > On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
> > >
> > > I suspect namespace borkage. But just because you pin-pointed
> > > my patch I'll try to track it down :)
> >
> > Surprise surprise. The namespace seq patch missed two spots in
> > AF_PACKET.
> >
> > [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
> >
> > The seq_open_net patch changed the meaning of seq->private.
> > Unfortunately it missed two spots in AF_PACKET, which still
> > used the old way of dereferencing seq->private, thus causing
> > weird and wonderful crashes when reading /proc/net/packet.
> >
> > This patch fixes them.
> >
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >
> > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > index 485af56..43e49f4 100644
> > --- a/net/packet/af_packet.c
> > +++ b/net/packet/af_packet.c
> > @@ -1878,7 +1878,7 @@ static void *packet_seq_start(struct seq_file *seq, loff_t *pos)
> >
> > static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> > {
> > - struct net *net = seq->private;
> > + struct net *net = seq_file_net(seq);
> > ++*pos;
> > return (v == SEQ_START_TOKEN)
> > ? sk_head(&net->packet.sklist)
> > @@ -1887,7 +1887,7 @@ static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> >
> > static void packet_seq_stop(struct seq_file *seq, void *v)
> > {
> > - struct net *net = seq->private;
> > + struct net *net = seq_file_net(seq);
> > read_unlock(&net->packet.sklist_lock);
> > }
> >
>
> ...
>
>
> Hmm. I tried compiling again with this patch applied and lockdep
> turned back on, and got the following (I will try again with lockdep
> turned back off):
>
> Dec 15 13:44:39 syntropy kernel: process `cat' is using deprecated
> sysctl (syscall) net.ipv6.neigh.default.retrans_time; Use
> net.ipv6.neigh.default.retrans_time_ms instead.
> Dec 15 13:44:39 syntropy kernel:
> Dec 15 13:44:39 syntropy kernel: =====================================
> Dec 15 13:44:39 syntropy kernel: [ BUG: bad unlock balance detected! ]
> Dec 15 13:44:39 syntropy kernel: -------------------------------------
> Dec 15 13:44:39 syntropy kernel: cat/4819 is trying to release lock
> (kkkkkkk<A5><BB><BB><BB><BB>Ȧ<FD><DF>) at:
> Dec 15 13:44:39 syntropy kernel: [packet_seq_stop+0xe/0x10]
> packet_seq_stop+0xe/0x10
> Dec 15 13:44:39 syntropy kernel: but there are no more locks to release!
> Dec 15 13:44:39 syntropy kernel:
> Dec 15 13:44:39 syntropy kernel: other info that might help us debug this:
> Dec 15 13:44:39 syntropy kernel: 2 locks held by cat/4819:
> Dec 15 13:44:39 syntropy kernel: #0: (&p->lock){--..}, at:
> [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
So your kernel is still feeding garbage into lockdep.
Are you really really sure that kernel had Herbert's patch applied?
^ permalink raw reply
* Re: Fw: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: Herbert Xu @ 2007-12-16 8:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Miles Lane, netdev, linux-kernel
In-Reply-To: <20071215235604.1a3f970a.akpm@linux-foundation.org>
On Sat, Dec 15, 2007 at 11:56:04PM -0800, Andrew Morton wrote:
> On Sun, 16 Dec 2007 01:37:01 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
>
> > > On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
So I posted this patch after 19:00 PST on 15 Dec.
> > Dec 15 13:44:39 syntropy kernel: #0: (&p->lock){--..}, at:
> > [crypto_algapi:seq_read+0x25/0x191c1] seq_read+0x25/0x26f
>
> So your kernel is still feeding garbage into lockdep.
>
> Are you really really sure that kernel had Herbert's patch applied?
The above log message is stamped as 13:44 PST. I gotta say
this doesn't look good :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode
From: Ingo Molnar @ 2007-12-16 8:58 UTC (permalink / raw)
To: Herbert Xu
Cc: Alexey Kuznetsov, Wang Chen, Gerrit Renker, davem, andi, netdev,
Linux Kernel Mailing List, Christoph Lameter
In-Reply-To: <20071216023621.GB959@gondor.apana.org.au>
* Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
> >
> > we could perhaps introduce stat_smp_processor_id(), which signals that
> > the CPU id is used for statistical purposes and does not have to be
> > exact? In any case, your patch looks good too.
>
> Unfortunately that doesn't work because we can then have two CPUs
> trying to update the same counter which may corrupt it.
ah, indeed. I missed that correctness aspect of your patch. Good catch!
Ingo
^ permalink raw reply
* Re: [RFC] mac80211: clean up frame receive handling
From: Ron Rindjunsky @ 2007-12-16 9:28 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, netdev, Michael Wu, Tomas Winkler, Jouni Malinen
In-Reply-To: <1197483844.6558.158.camel@johannes.berg>
> @@ -1150,14 +1148,27 @@ ieee80211_deliver_skb(struct ieee80211_t
> - if (local->bridge_packets && (sdata->type == IEEE80211_IF_TYPE_AP
> - || sdata->type == IEEE80211_IF_TYPE_VLAN) &&
> + dst = skb->data;
> +
> + if (compare_ether_addr(dev->dev_addr, dst) == 0)
> + skb->pkt_type = PACKET_HOST;
> + else if (is_multicast_ether_addr(dst)) {
> + if (is_broadcast_ether_addr(dst))
> + skb->pkt_type = PACKET_BROADCAST;
> + else
> + skb->pkt_type = PACKET_MULTICAST;
> + } else
> + skb->pkt_type = PACKET_OTHERHOST;
> +
> + if (local->bridge_packets && (sdata->type == IEEE80211_IF_TYPE_AP ||
> + sdata->type == IEEE80211_IF_TYPE_VLAN) &&
i may miss something, but wouldn't you prefer to use eth_type_trans
here and just add compare_ether_addr check after it?
> @@ -1186,16 +1197,18 @@ ieee80211_deliver_skb(struct ieee80211_t
>
> if (skb) {
> /* deliver to local stack */
> - skb->protocol = eth_type_trans(skb, dev);
> memset(skb->cb, 0, sizeof(skb->cb));
> + skb->dev = dev;
> + skb_reset_mac_header(skb);
> + skb_pull(skb, ETH_HLEN);
> netif_rx(skb);
> }
>
^ permalink raw reply
* Re: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
From: Mariusz Kozlowski @ 2007-12-16 10:48 UTC (permalink / raw)
To: Herbert Xu; +Cc: akpm, jgarzik, linux-kernel, netdev, davem, den, xemul
In-Reply-To: <20071216034119.GA1491@gondor.apana.org.au>
Hello,
> Surprise surprise. The namespace seq patch missed two spots in
> AF_PACKET.
>
> [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
>
> The seq_open_net patch changed the meaning of seq->private.
> Unfortunately it missed two spots in AF_PACKET, which still
> used the old way of dereferencing seq->private, thus causing
> weird and wonderful crashes when reading /proc/net/packet.
>
> This patch fixes them.
True :) It fixes both my x86 and sprac64. Thanks.
Mariusz
^ permalink raw reply
* Re: oops with 2.6.23.1, marvel, software raid, reiserfs and samba
From: Andrew Morton @ 2007-12-16 11:05 UTC (permalink / raw)
To: jeffunit; +Cc: linux-kernel, netdev
In-Reply-To: <20071208035018.JENM21128.mta13.adelphia.net@dual-xeon.jeffunit.com>
On Fri, 07 Dec 2007 19:49:52 -0800 jeffunit <jeff@jeffunit.com> wrote:
> I am running linux kernel 2.6.23.1, which I compiled.
> The base system was mandriva 2008.
>
> I have a dual processor pentium III 933 system.
> It has 3gb of ram, an intel stl-2 motherboard.
> It also has a promise 100 tx2 pata controller,
> a supermicro marvell based 8 port pcix sata controller,
> and a nvidia pci based video card.
>
> I have the os on a pata drive, and have made a software raid array
> consisting of 4 sata drives attached to the pcix sata controller.
> I created the array, and formatted with reiserfs 3.6
> I have run bonnie++ (filesystem benchmark) on the array without incident.
> When I use samba-3.0.25b-4.3 and copy files from a windows machine to
> the fileserver,
> every so often, the fileserver crashes or hangs. It seems to happen
> more often under heavy samba traffic.
> Enclosed is the oops from syslog.
> I also have a 'kernel bug' from syslog if that would be helpful.
>
> jeff
>
>
> Dec 7 17:20:52 sata_fileserver kernel: BUG: unable to handle kernel
> NULL pointer dereference at virtual address 0000000d
> Dec 7 17:20:52 sata_fileserver kernel: printing eip:
> Dec 7 17:20:52 sata_fileserver kernel: c02cc820
> Dec 7 17:20:52 sata_fileserver kernel: *pde = 00000000
> Dec 7 17:20:52 sata_fileserver kernel: Oops: 0000 [#1]
> Dec 7 17:20:52 sata_fileserver kernel: SMP
> Dec 7 17:20:52 sata_fileserver kernel: Modules linked in: raid456
> async_xor async_memcpy async_tx xor iptable_raw xt_comment xt_policy
> xt_multiport ipt_ULOG ipt_TTL ipt_ttl ipt_TOS ipt_tos ipt_SAME
> ipt_REJECT ipt_REDIRECT ipt_recent ipt_owner ipt_NETMAP
> ipt_MASQUERADE ipt_LOG ipt_iprange ipt_ECN ipt_ecn ipt_CLUSTERIP
> ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip
> nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp
> nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_tftp
> nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp
> nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
> nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss
> xt_pkttype xt_physdev xt_NFQUEUE xt_NFLOG xt_MARK xt_mark xt_mac
> xt_limit xt_length xt_helper xt_hashlimit ip6_tables xt_dccp
> xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY nfsd xt_tcpudp
> exportfs auth_rpcgss xt_state iptable_nat nf_nat nf_conntrack_ipv4
> nf_conntrack nfs iptable_mangle lockd nfs_acl sunrpc nfnetlink
> iptable_filter ip_table
> Dec 7 17:20:52 sata_fileserver kernel: x_tables af_packet ipv6
> snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss
> snd_mixer_oss ipmi_si ipmi_msghandler binfmt_misc loop nls_utf8 ntfs
> dm_mod usb_storage sg sd_mod sata_mv libata scsi_mod video output
> thermal sbs processor fan container button dock battery ac floppy
> snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm
> snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep
> ehci_hcd snd ohci_hcd i2c_piix4 uhci_hcd soundcore e1000 sworks_agp
> i2c_core ide_cd usbcore agpgart emu10k1_gp gameport tsdev evdev
> reiserfs ide_disk serverworks pdc202xx_new ide_core
> Dec 7 17:20:52 sata_fileserver kernel: CPU: 1
> Dec 7 17:20:52 sata_fileserver kernel:
> EIP: 0060:[<c02cc820>] Not tainted VLI
> Dec 7 17:20:52 sata_fileserver kernel: EFLAGS: 00210202 (2.6.23.1 #1)
> Dec 7 17:20:52 sata_fileserver kernel: EIP is at tcp_recvmsg+0x150/0xbf0
> Dec 7 17:20:52 sata_fileserver kernel: eax: 00000000 ebx:
> f55c4b60 ecx: 784e2c7c edx: f63f63d8
> Dec 7 17:20:52 sata_fileserver kernel: esi: 784e2c7a edi:
> f63f614c ebp: e21fde24 esp: e21fddc4
> Dec 7 17:20:52 sata_fileserver kernel: ds: 007b es: 007b fs:
> 00d8 gs: 0033 ss: 0068
> Dec 7 17:20:52 sata_fileserver kernel: Process smbd (pid: 9524,
> ti=e21fc000 task=f5109000 task.ti=e21fc000)
> Dec 7 17:20:52 sata_fileserver kernel: Stack: 00000000 ffffffff
> 00000000 c13e5740 f557b000 c03fa300 00000000 e21fde90
> Dec 7 17:20:52 sata_fileserver kernel: f63f60e0 00000000
> 00000b64 f63f63d8 000005b4 00000001 00000000 00000000
> Dec 7 17:20:52 sata_fileserver kernel: 00000000 000005b4
> e21fde4c 7fffffff e21fde28 00000000 c03a4de0 e21fde90
> Dec 7 17:20:52 sata_fileserver kernel: Call Trace:
> Dec 7 17:20:53 sata_fileserver kernel: [<c010542a>]
> show_trace_log_lvl+0x1a/0x30
> Dec 7 17:20:53 sata_fileserver kernel: [<c01054eb>]
> show_stack_log_lvl+0xab/0xd0
> Dec 7 17:20:53 sata_fileserver kernel: [<c01056e1>]
> show_registers+0x1d1/0x2d0
> Dec 7 17:20:53 sata_fileserver kernel: [<c01058f6>] die+0x116/0x250
> Dec 7 17:20:53 sata_fileserver kernel: [<c011f52b>] do_page_fault+0x28b/0x6a0
> Dec 7 17:20:53 sata_fileserver kernel: [<c030938a>] error_code+0x72/0x78
> Dec 7 17:20:53 sata_fileserver kernel: [<c0295423>]
> sock_common_recvmsg+0x43/0x60
> Dec 7 17:20:53 sata_fileserver kernel: [<c029301c>] sock_aio_read+0x11c/0x130
> Dec 7 17:20:53 sata_fileserver kernel: [<c017db30>] do_sync_read+0xd0/0x110
> Dec 7 17:20:53 sata_fileserver kernel: [<c017e47d>] vfs_read+0x12d/0x140
> Dec 7 17:20:53 sata_fileserver kernel: [<c017e8bd>] sys_read+0x3d/0x70
> Dec 7 17:20:53 sata_fileserver kernel: [<c01042fe>]
> sysenter_past_esp+0x6b/0xa1
> Dec 7 17:20:53 sata_fileserver kernel: =======================
> Dec 7 17:20:53 sata_fileserver kernel: Code: 6c 39 df 74 59 8d b6 00
> 00 00 00 85 db 74 4f 8b 55 cc 8d 43 20 8b 0a 3b 48 18 0f 88 f4 05 00
> 00 89 ce 2b 70 18 8b 83 90 00 00 00 <0f> b6 50 0d 89 d0 83 e0 02 3c
> 01 8b 43 50 83 d6 ff 39 c6 0f 82
> Dec 7 17:20:53 sata_fileserver kernel: EIP: [<c02cc820>]
> tcp_recvmsg+0x150/0xbf0 SS:ESP 0068:e21fddc4
> Dec 7 17:21:11 sata_fileserver kernel:
> Shorewall:net2all:DROP:IN=eth0 OUT=
> MAC=00:04:23:a8:12:cf:00:11:2f:42:d4:32:08:00 SRC=192.168.47.120
> DST=192.168.47.101 LEN=60 TOS=0x00 PREC=0x00 TTL=32 ID=9964
> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=24064
> Dec 7 17:21:13 sata_fileserver kernel:
> Shorewall:net2all:DROP:IN=eth0 OUT=
> MAC=00:04:23:a8:12:cf:00:11:2f:42:d4:32:08:00 SRC=192.168.47.120
> DST=192.168.47.101 LEN=60 TOS=0x00 PREC=0x00 TTL=32 ID=9975
> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=24320
(Please try to avoid the wordwrapping).
That's a networking crash. Do the oops traces which you're getting all look
like this one?
Pentium III's are getting a bit old (resistive connections, drooping
power supplies, etc) so there's a decent chance that you're seeing
hardware failures here.
^ permalink raw reply
* WINNERS IN LRP DRAW!!!
From: inforheinlandpfalz01 @ 2007-12-16 11:23 UTC (permalink / raw)
LOTTO!!!
Ferdinand-Sauerbruch-Strasse 2
DE-56073 Koblenz.Germany.
Reference Number: LRP/19-DE/9317
Batch: LRP/07/38
You have therefore been approved for a lump sum payout of €1,000,000.00 (One Million EURO) in cash credited to file LRP/19-DE/9317.Contact below
Mr.Wilson Gart
Email: info@lrpwilson02.vossnet.co.uk
Phone: 00 44 870 479 9332
Yours faithfully,
Hans-Peter Schossler
^ permalink raw reply
* Re: [PATCH] MACB: clear transmit buffers properly on TX Underrun
From: Gregory CLEMENT @ 2007-12-16 11:37 UTC (permalink / raw)
To: Haavard Skinnemoen; +Cc: netdev, linux-arm-kernel
In-Reply-To: <20071213123308.156ab7dd@dhcp-252-066.norway.atmel.com>
Haavard Skinnemoen a écrit :
> On Thu, 13 Dec 2007 08:51:57 +0100
> Gregory CLEMENT <novexz@gmail.com> wrote:
>
>> Hi,
>> I generated this patch for linux 2.6.24-rc5 and test it on AT91SAM9263
>> with iperf.
>>
>> From: Gregory CLEMENT <gclement00@gmail.com>
>> Date: Wed, 12 Dec 2007 18:10:14 +0100
>> Subject: [PATCH] MACB: clear transmit buffers properly on TX Underrun
>>
>> Initially transmit buffer pointers were only reset. But buffer descriptors
>> were possibly still set as ready, and buffer in upper layer was not
>> freed. This caused driver hang under big load.
>> Now reset clean properly the buffer descriptor and freed upper layer.
>
> Nice. I think we want this for 2.6.24.
>
> But the patch is a bit mangled, so I don't think it will apply. Please
> have a look in Documentation/email-clients.txt for information on how
> to set up Thunderbird to avoid this.
I read it and apply it. Hope it will be OK as I didn't see any problem in m first mail...
>
>> Signed-off-by: Gregory CLEMENT <gclement00@gmail.com>
>> ---
>> drivers/net/macb.c | 26 +++++++++++++++++++++++++-
>> 1 files changed, 25 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>> index 047ea7b..2ee1dab 100644
>> --- a/drivers/net/macb.c
>> +++ b/drivers/net/macb.c
>> @@ -307,9 +307,33 @@ static void macb_tx(struct macb *bp)
>> (unsigned long)status);
>>
>> if (status & MACB_BIT(UND)) {
>> + int i;
>> printk(KERN_ERR "%s: TX underrun, resetting buffers\n",
>> - bp->dev->name);
>> + bp->dev->name);
>> +
>> + head = bp->tx_head;
>> +
>> + /* free transmit buffer in upper layer*/
>> + for (tail = bp->tx_tail; tail != head; tail = NEXT_TX(tail)) {
>> + struct ring_info *rp = &bp->tx_skb[tail];
>> + struct sk_buff *skb = rp->skb;
>> +
>> + BUG_ON(skb == NULL);
>> +
>> + rmb();
>> +
>> + dma_unmap_single(&bp->pdev->dev, rp->mapping, skb->len,
>> + DMA_TO_DEVICE);
>> + rp->skb = NULL;
>> + dev_kfree_skb_irq(skb);
>> + }
>> +
>> + /*Mark all the buffer as used to avoid sending a lost buffer*/
>> + for (i = 0; i < RX_RING_SIZE; i++)
>> + bp->tx_ring[i].ctrl = MACB_BIT(TX_USED);
>
> That should be TX_RING_SIZE, shouldn't it?
Yes I fixed it
>
> I also think this should be done as part of the previous loop, before
> they are freed. Having free buffers in the ring sounds dangerous, even
> if it's only for a short time.
OK, I moved this loop before the previous loop, as I wanted to be sure that
all buffers are marked.
I did it, but I think we don't really need to do it, as when underrun happen,
controller stop transmitting, so it won't transmit a free buffer.
>
>> +
>> bp->tx_head = bp->tx_tail = 0;
>
> Now, I wonder if it would be better to just scan the ring descriptors,
> find the one that failed and just move the DMA pointer to the next
> entry. The hardware resets the DMA pointer when an underrun happens, so
> I think your code will work, but we're losing more packets than
> strictly necessary. In any case, it's better than the existing code.
As hardware reset the DMA pointer, we have to rewrite all the buffer descriptor.
For example if descriptor n°78 failed, and there is descriptor 79 and 80 which
are pending. When underrun happen on 78 the hardware reset DMA pointer which
will point on descriptor 0. So we have to copy descriptor 79 on 0 and 80 on 1.
The other option is to change Transmit Buffer Queue Pointer Register (TBQP), to
make it point on descriptor 79, but on the next descriptor having wrapped bit set,
the DMA pointer will wrapped on descriptor 79 and not on 0. So I don't think it
is a good solution.
> Perhaps we need a check in macb_start_xmit() as well to avoid starting
> a transmission when the ring has just been reset.
>
I joined the patch change along your recommendation, if there is no more error, you
can maybe submit it for 2.6.24 release, and other improvement can be done later.
From: Gregory CLEMENT <gclement00@gmail.com>
Date: Sun, 16 Dec 2007 11:45:03 +0100
Subject: [PATCH] MACB: clear transmit buffers properly on transmit underrun
Initially transmit buffer pointers were only reset. But buffer descriptors
were possibly still set as ready, and buffer in upper layer was not
freed. This caused driver hang under big load.
Now reset clean properly the buffer descriptor and freed upper layer.
Signed-off-by: Gregory CLEMENT <gclement00@gmail.com>
---
drivers/net/macb.c | 27 ++++++++++++++++++++++++++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 047ea7b..e898713 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -307,9 +307,34 @@ static void macb_tx(struct macb *bp)
(unsigned long)status);
if (status & MACB_BIT(UND)) {
+ int i;
printk(KERN_ERR "%s: TX underrun, resetting buffers\n",
- bp->dev->name);
+ bp->dev->name);
+
+ head = bp->tx_head;
+
+ /*Mark all the buffer as used to avoid sending a lost buffer*/
+ for (i = 0; i < TX_RING_SIZE; i++)
+ bp->tx_ring[i].ctrl = MACB_BIT(TX_USED);
+
+ /* free transmit buffer in upper layer*/
+ for (tail = bp->tx_tail; tail != head; tail = NEXT_TX(tail)) {
+ struct ring_info *rp = &bp->tx_skb[tail];
+ struct sk_buff *skb = rp->skb;
+
+ BUG_ON(skb == NULL);
+
+ rmb();
+
+ dma_unmap_single(&bp->pdev->dev, rp->mapping, skb->len,
+ DMA_TO_DEVICE);
+ rp->skb = NULL;
+ dev_kfree_skb_irq(skb);
+ }
+
+
bp->tx_head = bp->tx_tail = 0;
+
}
if (!(status & MACB_BIT(COMP)))
--
1.5.2.5
^ permalink raw reply related
* Re: oops with 2.6.23.1, marvel, software raid, reiserfs and samba
From: Herbert Xu @ 2007-12-16 11:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: jeff, linux-kernel, netdev, davem
In-Reply-To: <20071216030516.1562a5d0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> Dec 7 17:20:53 sata_fileserver kernel: Code: 6c 39 df 74 59 8d b6 00
>> 00 00 00 85 db 74 4f 8b 55 cc 8d 43 20 8b 0a 3b 48 18 0f 88 f4 05 00
>> 00 89 ce 2b 70 18 8b 83 90 00 00 00 <0f> b6 50 0d 89 d0 83 e0 02 3c
>> 01 8b 43 50 83 d6 ff 39 c6 0f 82
This means that skb->network_header == NULL so this line crashes:
if (tcp_hdr(skb)->syn)
offset--;
> That's a networking crash. Do the oops traces which you're getting all look
> like this one?
What's spooky is that I just did a google and we've had reports
since 1998 all crashing on exactly the same line in tcp_recvmsg.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: oops with 2.6.23.1, marvel, software raid, reiserfs and samba
From: Herbert Xu @ 2007-12-16 12:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: jeff, linux-kernel, netdev, davem
In-Reply-To: <E1J3s76-000166-00@gondolin.me.apana.org.au>
On Sun, Dec 16, 2007 at 07:56:56PM +0800, Herbert Xu wrote:
>
> What's spooky is that I just did a google and we've had reports
> since 1998 all crashing on exactly the same line in tcp_recvmsg.
However, there's been no reports at all since 2000 apart from this
one so the earlier ones are probably not related.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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