Re: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 11:09 PM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:41 PM, Gabriel C [EMAIL PROTECTED] wrote: Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. -rc5 works great. Really don't know what's different between my -rc3 and -rc5 builds. The diff of .config between the two doesn't show anything obvious, so perhaps it was something fixed in the interim. I've gone ahead and closed the bugzilla entry, btw. Thanks, and sorry for the false (or tardy) alarm. Ray -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SACK scoreboard (Was: Re: [RFC PATCH net-2.6.25 uncompilable] [TCP]: Avoid breaking GSOed skbs when SACKed one-by-one)
On Tue, 11 Dec 2007, David Miller wrote:
Interesting approach, but I think there is limited value to this
(arguably) complex form.
The core issue is that the data and the SACK state are maintained in
the same datastructure. The complexity in all the state management
and fixups in your patch is purely because of this.
Yeah, had just too much time while waiting for person who never
arrived... :-) It would have covered the typical case quite well
tough, for sure it was very intrusive.
If we maintain SACK scoreboard information seperately, outside of
the SKB, then there are only two changes to make:
1) Every access to TCP_SKB_CB() SACK scoreboard is adjusted to
new data structure.
Not sure if it is going to all that straightforward because you seem to
ignore in this simple description all details of performing the linking
between the structures, which becomes tricky when we add those
retransmission adjustments.
2) Retransmit is adjusted so that it can retransmit an SKB
constructed as a portion of an existing SKB. Since TSO
implies SG, this can be handled with simple offset and
length arguments and suitable creation of a clone referencing
the pages in the SG vector that contain the desired data.
...I.e., how to count retrans_out origins in such case because the
presented sack_ref knows nothing about them nor do we have anything but
one bit in -sacked per skb. We need the origins when retransmission get
sacked/acked to reduce retrans_out correctly. To solve this, I think the
sack_ref must have -sacked as well and the structure should store the
R-bits there as well, and may L-bits too though their defination is
more obvious because it's mostly a complement of sacked (except for small
part near fackets_out and timedout marking that probably makes bookkeeping
of L still necessary).
The pcount boundaries are no longer that well defined after we break skb
boundaries during retransmitting, so doing this makes fackets_out
calculation even more trickier to track, unless whole pcount is replaced
by byte based fackets_out :-/, which is very trivial to determine from
seqnos only (TCP_NODELAYers might get unhappy though if we do that in a
straightforward way...).
This would clearly be a good step from one perspective. Nowadays GSO'ed
skbs may get fragmented when mss_now changes, for two or more consecutive
non-SACKed skbs that means one or more extra (small) packets when
retransmitting.
I would envision this SACK state thing to reference into the
retransmit queue SKB's somehow. Each SACK block could perhaps
look something like:
struct sack_ref {
struct sk_buff *start_skb;
struct sk_buff *end_skb;
unsigned int start_off;
unsigned int len;
};
...I assume that these are fast searchable? And skbs as well (because the
linking of start/end_skb at minimum is a costly operation otherwise)?
--
i.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/29] mm: slb: add knowledge of reserve pages
On Friday 14 December 2007 14:51, I wrote: On Friday 14 December 2007 07:39, Peter Zijlstra wrote: Note that false sharing of slab pages is still possible between two unrelated writeout processes, both of which obey rules for their own writeout path, but the pinned combination does not. This still leaves a hole through which a deadlock may slip. Actually, no it doesn't. It in fact does not matter how many unrelated writeout processes, block devices, whatevers share a slab cache. Sufficient reserve pages must have been made available (in a perfect work, by adding extra pages to the memalloc reserve on driver initialization, in the real world just by having a big memalloc reserve) to populate the slab up to the sum of the required objects for all memalloc users sharing the cache. So I think this slab technique of yours is fundamentally sound, that is to say, adding a new per-slab flag to keep unbounded numbers of slab objects with unbounded lifetimes from mixing with the bounded number of slab objects with bounded lifetimes. Ponder. OK, here is another issue. Suppose a driver expands the memalloc reserve by the X number of pages it needs on initialization, and shrinks it by the same amount on removal, as is right and proper. The problem is, less than the number of slab pages that got pulled into slab on behalf of the removed driver may be freed (or made freeable) back to the global reserve, due to page sharing with an unrelated user. In theory, the global reserve could be completely depleted by this slab fragmentation. OK, that is like the case that I mistakenly raised in the previous mail, though far less likely to occur, because driver removals are relatively rare and so would be a fragmentation case so severe as to cause global reserve depletion. Even so, if this possibility bothers anybody, it is fairly easy to plug the hole: associate each slab with a given memalloc user instead of just having one bit to classify users. So unrelated memalloc users would never share a slab, no false sharing, everybody happy. The cost: a new pointer field per slab and a few additional lines of code. Regards, Daniel -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH take2] [AX25] circular locking with AX25 connection timeout
On Fri, Dec 14, 2007 at 11:29:28PM +0100, Bernard Pidoux wrote:
Hi,
This patch cancels a circular locking conflict that appeared with a timeout
of an AX25 connection.
signed off by Jarek Poplawski
One spurious space less here, and maybe a few more words to the changelog.
Regards,
Jarek P.
Subject: [PATCH] [NET] AX25: locking dependencies fix in ax25_disconnect
Bernard Pidoux reported these lockdep warnings:
[ INFO: possible irq lock inversion dependency detected ]
2.6.23.1 #1
-
fpac/4933 just changed the state of lock:
(slock-AF_AX25){--..}, at: [d8be3312] ax25_disconnect+0x46/0xaf
[ax25]
but this lock was taken by another, soft-irq-safe lock in the past:
(ax25_list_lock){-+..}
and interrupts could create inverse lock ordering between them.
[...]
[ INFO: inconsistent lock state ]
2.6.23.1 #1
-
inconsistent {in-softirq-W} - {softirq-on-W} usage.
ax25_call/4005 [HC0[0]:SC0[0]:HE1:SE1] takes:
(slock-AF_AX25){-+..}, at: [d8b79312] ax25_disconnect+0x46/0xaf [ax25]
[...]
This means slock-AF_AX25 could be taken both from softirq and process
context with softirqs enabled, so it's endangered itself, but also makes
ax25_list_lock vulnerable. It was not 100% verified if the real lockup
can happen, but this fix isn't very costly and looks safe anyway.
(It was tested by Bernard with 2.6.23.9 and 2.6.24-rc5 kernels.)
Reported_by: Bernard Pidoux [EMAIL PROTECTED]
Tested_by: Bernard Pidoux [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.24-rc2-/net/ax25/ax25_subr.c
linux-2.6.24-rc2+/net/ax25/ax25_subr.c
--- linux-2.6.24-rc2-/net/ax25/ax25_subr.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.24-rc2+/net/ax25/ax25_subr.c 2007-11-28 11:51:12.0
+0100
@@ -279,6 +279,7 @@ void ax25_disconnect(ax25_cb *ax25, int
ax25_link_failed(ax25, reason);
if (ax25-sk != NULL) {
+ local_bh_disable();
bh_lock_sock(ax25-sk);
ax25-sk-sk_state = TCP_CLOSE;
ax25-sk-sk_err = reason;
@@ -288,5 +289,6 @@ void ax25_disconnect(ax25_cb *ax25, int
sock_set_flag(ax25-sk, SOCK_DEAD);
}
bh_unlock_sock(ax25-sk);
+ local_bh_enable();
}
}
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reproducible data corruption with sendfile+vsftp - splice regression?
On Thu, 13 Dec 2007 03:19:43 +0100, Holger Hoffstaette wrote: I have now gone back to enable TSO since vsftp with sendfile really seems to be the only app that causes this. I have simply set it to use_sendfile=NO and no corruption occurs at all; the machine is stable and fast. In the good tradition of proving myself wrong I can reliably create corrupted files by wget-ting from apache (with sendfile enabled) as well, so no more TSO after all. No TSO, no corruption. The same also happens on a different machine with a r8169 (same model). Tickless kernel makes no difference either. Shot in the dark, but hey.. Holger -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETFILTER] xt_hashlimit : speedups hash_dst()
Eric Dumazet wrote, On 12/14/2007 10:37 PM: Jarek Poplawski a écrit : Eric Dumazet wrote, On 12/14/2007 12:09 PM: ... + /* +* Instead of returning hash % ht-cfg.size (implying a divide) +* we return the high 32 bits of the (hash * ht-cfg.size) that will +* give results between [0 and cfg.size-1] and same hash distribution, +* but using a multiply, less expensive than a divide +*/ + return ((u64)hash * ht-cfg.size) 32; Are we sure of the same hash distribution? Probably I miss something, but: if this 'hash' is well distributed on 32 bits, and ht-cfg.size is smaller than 32 bits, e.g. 256 (8 bits), then this multiplication moves to the higher 32 of u64 only max. 8 bits of the most significant byte, and the other three bytes are never used, while division is always affected by all four bytes... Not sure what you are saying... but if size=256, then, yes, we want a final result between 0 and 255, so three bytes are nul. Eric, it would be nice to acknowledge David's suggestion that this hash size is always power of two here, because otherwise at least your words about the same hash distribution according to the % variant could be wrong (but I don't say the final result would be wrong). Maybe I mix up these sizes, but it seems this could be set by a user, and I didn't find anything about this power of two necessity? Regards, Jarek P. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
On Sat, 15 Dec 2007 14:10:21 +0800 Herbert Xu [EMAIL PROTECTED] wrote: On Fri, Dec 14, 2007 at 09:44:18PM -0800, Andrew Morton wrote: That sounds like a bug in mutex_trylock() to me. I was relying on http://kerneltrap.org/mailarchive/linux-netdev/2007/9/28/325129 which seems to be a bogus claim now that I actually look at the source code. So in that case I'm OK with your patch as long as it warns about hard IRQ usage. When Eric said Way way deep in mutex debugging on the slowpath there is a unreadable and incomprehensible WARN_ON in muxtex_trylock that will trigger if you have 10 tons of debugging turned on, and you are in, interrupt context, and you manage to hit the slow path. I think that is a pretty unlikely scenario. I think he's still right. That's if the warning which he managed to find even still exists. I think the change which Eric proposed is a good one: it converts ASSERT_RTNL() from an atomic rmw which dirties a cacheline which will sometimes be owned by a different CPU into a plain old read. It's going to make ASSERT_RTNL() heaps cheaper. looks at mutex_is_locked(), rofls at static inline fastcall, fixes it 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. If you want to check that no locks are held (which I think is a bit weird, but whatever) then add might_sleep(). If you want to check that we're not in interrupt context or whatever, then add the checks and be happy. might_sleep() will of course check for in_interrupt(), in_irq(), etc so if you go with a might_sleep() then nothing else needs to be added. While doing this I'd also suggest that the thing should be uninlined - it'll probably generate less text and it'll give considerably more flexibility for adding new debug fetures. Ones which might be controlled at compile time or runtime. ie: void __assert_rtnl(const char *file, int line); #define ASSERT_RTNL() __assert_rtnl(__FILE__, __LINE__) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETFILTER] xt_hashlimit : speedups hash_dst()
Jarek Poplawski a écrit : Eric Dumazet wrote, On 12/14/2007 10:37 PM: Jarek Poplawski a écrit : Eric Dumazet wrote, On 12/14/2007 12:09 PM: ... + /* +* Instead of returning hash % ht-cfg.size (implying a divide) +* we return the high 32 bits of the (hash * ht-cfg.size) that will +* give results between [0 and cfg.size-1] and same hash distribution, +* but using a multiply, less expensive than a divide +*/ + return ((u64)hash * ht-cfg.size) 32; Are we sure of the same hash distribution? Probably I miss something, but: if this 'hash' is well distributed on 32 bits, and ht-cfg.size is smaller than 32 bits, e.g. 256 (8 bits), then this multiplication moves to the higher 32 of u64 only max. 8 bits of the most significant byte, and the other three bytes are never used, while division is always affected by all four bytes... Not sure what you are saying... but if size=256, then, yes, we want a final result between 0 and 255, so three bytes are nul. Eric, it would be nice to acknowledge David's suggestion that this hash size is always power of two here, because otherwise at least your words about the same hash distribution according to the % variant could be wrong (but I don't say the final result would be wrong). Maybe I mix up these sizes, but it seems this could be set by a user, and I didn't find anything about this power of two necessity? size is not a power of two here. 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. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} - {softirq-on-R} usage.
On Fri, 14 Dec 2007 22:58:24 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 14, 2007 6:36 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 17:13:21 -0500
Miles Lane [EMAIL PROTECTED] 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 =
Oops: [#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: fffe
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 0400 c05b74f4 0001 c05b78f4
c048f503 0400 d5a09000 0002 d6267d0c c01fdf41
d6267d94
db68c04a d6267d74 c012ae81 d6267d94 0028 c05b89f7 00200046
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:
[PATCH] sky2: check pci_register_driver() error
Check pci_register_driver() error and clean up debugfs entries
if error happened.
Cc: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
---
drivers/net/sky2.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
Index: 2.6-git/drivers/net/sky2.c
===
--- 2.6-git.orig/drivers/net/sky2.c
+++ 2.6-git/drivers/net/sky2.c
@@ -4426,8 +4426,15 @@ static struct pci_driver sky2_driver = {
static int __init sky2_init_module(void)
{
+ int err;
+
sky2_debug_init();
- return pci_register_driver(sky2_driver);
+ err = pci_register_driver(sky2_driver);
+ if (err) {
+ sky2_debug_cleanup();
+ return err;
+ }
+ return 0;
}
static void __exit sky2_cleanup_module(void)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
On Sat, Dec 15, 2007 at 02:48:10AM -0800, Andrew Morton wrote:
When Eric said
Way way deep in mutex debugging on the slowpath there is a unreadable
and incomprehensible WARN_ON in muxtex_trylock that will trigger if
you have 10 tons of debugging turned on, and you are in,
interrupt context, and you manage to hit the slow path. I think that
is a pretty unlikely scenario.
I think he's still right. That's if the warning which he managed to find
even still exists.
Well at the very start he said:
: When mutex debugging is on taking a mutex complains if we are not
: allowed to sleep. At that point we have called netif_tx_lock_bh
: so we are clearly not allowed to sleep. Arguably this is not a
: problem for mutex_trylock.
This is what threw me off as it implied that we were warning about
ASSERT_RTNL calls in any atomic context, including those with just
soft IRQs disabled, which is an important distinction for the
networking subsystem.
Had he said that it was just IRQ handlers rather than soft IRQs
then we wouldn't be having this discussion now :)
I think the change which Eric proposed is a good one: it converts
ASSERT_RTNL() from an atomic rmw which dirties a cacheline which will
sometimes be owned by a different CPU into a plain old read. It's going to
make ASSERT_RTNL() heaps cheaper.
I agree. Although paths using ASSERT_RTNL shouldn't be performance
critical since the RTNL should only be held for control operations
as opposed to data transport.
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reproducible data corruption with sendfile+vsftp - splice regression?
On Thu, 06 Dec 2007 19:44:26 +0100, Francois Romieu wrote: Holger Hoffstaette [EMAIL PROTECTED] : [...] Maybe turning off sendfile or NAPI just lead to random success - so far it really looks like tso on the r8169 is the common cause. TSO on the r8169 is the magic switch but the regression makes imvho more sense from a VM pov: - the corrupted file has the same size as the expected file - the corrupted file exhibits holes which come as a multiple of 4096 bytes (8*4k, 2 places, there may be more) - the r8169 driver does not know what a page is - the 8169 hardware has a small 8192 bytes Tx buffer It would be nice if someone could do a sendfile + vsftp test with TSO on a different hardware. While I could not reproduce the corruption when simply downloading a file that I had copied on the server with scp, it triggered almost immediately after I copied it locally and tried to download the copy. I tested 2.6.24-rc5 on my T60 (Intel e1000 built with NAPI) and installed vsftp/apache with sendfile and enabled all offload options incl. TSO. Repeated downloads of 500 MB with ftp or wget over the NIC onto ram- or physical disk gives no corruption whatsoever. Speed of download to ramdisk is a nice continuous 125 MB/sec. Looks like the r8169 or the driver after all.. thanks Holger -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
Never mind, we already have that in local_t and as Alexey correctly
points out, USER is still going to be the expensive variant with the
preempt_disable (well until BH gets threaded). So how about this patch?
I didn't hear any objections so here is the patch again.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context
which is illegal because the process may be preempted and then
migrated to another CPU.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/snmp.h b/include/net/snmp.h
index ea206bf..9444b54 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -23,6 +23,7 @@
#include linux/cache.h
#include linux/snmp.h
+#include linux/smp.h
/*
* Mibs are stored in array of unsigned long.
@@ -137,7 +138,10 @@ struct linux_mib {
#define SNMP_INC_STATS_OFFSET_BH(mib, field, offset) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())-mibs[field + (offset)]++)
#define SNMP_INC_STATS_USER(mib, field) \
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_INC_STATS(mib, field) \
(per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())-mibs[field]++)
#define SNMP_DEC_STATS(mib, field) \
@@ -145,6 +149,9 @@ struct linux_mib {
#define SNMP_ADD_STATS_BH(mib, field, addend) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())-mibs[field] += addend)
#define SNMP_ADD_STATS_USER(mib, field, addend)\
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field] += addend)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field] += addend; \
+ put_cpu(); \
+ } while (0)
#endif
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] datagram: mem_scheudle functions
On Mon, Dec 03, 2007 at 07:10:45PM -0500, Hideo AOKI wrote:
Because we have to call wmem_schedule function in ip_append_data()
which is used by several protocols both stream and datagram.
I just thought adding the sk_wmem_schedule() was only way to call
proper function from ip_append_data().
ip_append_data can't possibly work for stream protocols. So
which stream protocol is calling it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
On Dec 14, 2007 11:10 PM, Herbert Xu [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 05:47:22PM -0500, Andy Gospodarek wrote:
I'm guessing if we go back to using a write-lock for bond-lock this
will go back to working again, but I'm not totally convinced since there
are plenty of places where we used a read-lock with it.
Sorry I forgot to cc you earlier Andy.
But to fix this you need make sure that all read locks on bond-lock
in process context disable BH. This is because at least one write
lock can be taken from BH context.
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
You don't need to turn the read locks into write locks however.
This is also something that we can undo once the set_multicast
interface has been fixed to not take the tx lock.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [CORE]: datagram: mem_scheudle functions
On Sat, Dec 15, 2007 at 12:15:04AM -0500, Hideo AOKI wrote:
This patch includes changes in network core sub system for memory
accounting.
Memory scheduling, charging, uncharging and reclaiming functions are
added. These functions use sk_forward_alloc to store socket local
accounting. They also need to use lock to keep consistency of
sk_forward_alloc and memory_allocated. They currently support only
datagram protocols.
Thanks for the patch. I think it's generally on the right track
but there's still a few issues with the implementation.
+ spin_lock_irqsave(sk-sk_lock.slock, flags);
Please use bh_lock_sock since this must never be used from an
IRQ handler.
+static inline void sk_mem_reclaim(struct sock *sk)
+{
+ if (sk-sk_type == SOCK_DGRAM)
+ sk_datagram_mem_reclaim(sk);
+}
Please get rid of these wrappers since we should only get here
for datagram protocols.
+static inline int sk_account_wmem_charge(struct sock *sk, int size)
+{
+ unsigned long flags;
+
+ /* account if protocol supports memory accounting. */
+ if (!sk-sk_prot-memory_allocated || sk-sk_type != SOCK_DGRAM)
+ return 1;
+
+ spin_lock_irqsave(sk-sk_lock.slock, flags);
+ if (sk_datagram_wmem_schedule(sk, size)) {
+ sk-sk_forward_alloc -= size;
+ spin_unlock_irqrestore(sk-sk_lock.slock, flags);
+ return 1;
+ }
+ spin_unlock_irqrestore(sk-sk_lock.slock, flags);
+ return 0;
+}
This is probably too big to inline.
+static inline int sk_account_rmem_charge(struct sock *sk, int size)
+{
+ unsigned long flags;
+
+ /* account if protocol supports memory accounting. */
+ if (!sk-sk_prot-memory_allocated || sk-sk_type != SOCK_DGRAM)
+ return 1;
+
+ spin_lock_irqsave(sk-sk_lock.slock, flags);
+ if (sk_datagram_rmem_schedule(sk, size)) {
+ sk-sk_forward_alloc -= size;
+ spin_unlock_irqrestore(sk-sk_lock.slock, flags);
+ return 1;
+ }
+ spin_unlock_irqrestore(sk-sk_lock.slock, flags);
+ return 0;
+}
Why are we duplicating the rmem/wmem versions when they're identical?
-int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+int sock_queue_rcv_skb_with_owner(struct sock *sk, struct sk_buff *skb,
+ void set_owner_r(struct sk_buff *nskb,
+struct sock* nsk))
Just make a new function for this rather than playing with function
pointers.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} - {softirq-on-R} usage.
Andrew Morton wrote, On 12/15/2007 12:13 PM: On Fri, 14 Dec 2007 22:58:24 -0500 Miles Lane [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:36 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 14 Dec 2007 17:13:21 -0500 Miles Lane [EMAIL PROTECTED] wrote: ... Pid: 6944, comm: cat Not tainted (2.6.24-rc5-mm1 #26) ... note: cat[6944] exited with preempt_count 4 ... Dec 14 21:32:55 feargod kernel: cat/6180 is trying to release lock ... Can you suggest a way in which others can reproduce this? Buy a cat? Jarek P. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode
Herbert Xu a écrit :
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
Never mind, we already have that in local_t and as Alexey correctly
points out, USER is still going to be the expensive variant with the
preempt_disable (well until BH gets threaded). So how about this patch?
I didn't hear any objections so here is the patch again.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context
which is illegal because the process may be preempted and then
migrated to another CPU.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
#define SNMP_INC_STATS_USER(mib, field) \
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_INC_STATS(mib, field) \
(per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())-mibs[field]++)
How come you change SNMP_INC_STATS_USER() but not SNMP_INC_STATS() ?
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} - {softirq-on-R} usage.
Andrew Morton wrote, On 12/15/2007 12:13 PM:
On Fri, 14 Dec 2007 22:58:24 -0500 Miles Lane [EMAIL PROTECTED] wrote:
...
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
(kkk�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
Miles, I didn't check this yet, but since there were some considerable
changes, including locking, you could try with reverting some of these
last 3 patches to net/packet by Denis:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.25.git;a=history;f=net/packet/af_packet.c;h=485af5691d64270a02322925a6ccfad9d02b7f78;hb=HEAD
Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode
* Herbert Xu [EMAIL PROTECTED] wrote:
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
Never mind, we already have that in local_t and as Alexey correctly
points out, USER is still going to be the expensive variant with the
preempt_disable (well until BH gets threaded). So how about this patch?
I didn't hear any objections so here is the patch again.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context which is
illegal because the process may be preempted and then migrated to
another CPU.
nit: please use 'invalid' instead of 'illegal'.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field]++; \
+ put_cpu(); \
+ } while (0)
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field] += addend)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field] += addend; \
+ put_cpu(); \
+ } while (0)
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.
Ingo
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression: Wireshark sees no packets in 2.6.24-rc3
On Sat, 2007-12-15 at 00:16 -0800, Ray Lee wrote: On Dec 14, 2007 11:09 PM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:41 PM, Gabriel C [EMAIL PROTECTED] wrote: Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. -rc5 works great. Really don't know what's different between my -rc3 and -rc5 builds. I have an -rc3+wireless bits which also works great wrt. tcpdump/wireshark. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] e1000: Dump the eeprom when a user encounters a bad checksum
Joe Perches wrote: On Fri, 2007-12-14 at 15:35 -0800, Auke Kok wrote: +printk(KERN_ERR /*/\n); +printk(KERN_ERR Current EEPROM: 0x%04x\nCalculated: 0x%04x\n, + csum_old, csum_new); Multiline printks need a KERN_level after every newline. Perhaps: printk(KERN_ERR Current EEPROM: 0x%04x\n KERN_ERR Calculated: 0x%04x\n, csum_old, csum_new); +printk(KERN_ERR Offset Values\n); +printk(KERN_ERR == ==\n); +for (i = 0; i eeprom.len; i += 16) +printk(KERN_ERR 0x%04x + %02x %02x %02x %02x %02x %02x %02x %02x + %02x %02x %02x %02x %02x %02x %02x %02x\n, + i, data[i], data[i + 1], data[i + 2], data[i + 3], + data[i + 4], data[i + 5], data[i + 6], data[i + 7], + data[i + 8], data[i + 9], data[i + 10], data[i + 11], + data[i + 12], data[i + 13], data[i + 14], data[i + 15]); print_hex_dump(KERN_ERR, , DUMP_PREFIX_OFFSET, 16, 1, data, eeprom.len, true); +printk(KERN_ERR Include this output when contacting your support + provider.\n\nThis is not a software error! Something bad + happened to your hardware or\nEEPROM image. Ignoring this + problem could result in further problems,\npossibly loss + of data, corruption or system hangs!\n\n); +printk(KERN_ERR The MAC Address will be reset to 00:00:00:00:00:00, + which is invalid\nand requires you to set the proper MAC + address manually before continuing\nto enable this network + device.\n\n); +printk(KERN_ERR Please inspect the EEPROM dump and report the issue + to your hardware vendor\nor Intel Customer Support: + [EMAIL PROTECTED]); multiline printks... given these and Randy's comments I'll respin this and resubmit. thanks for the comments! Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1: cat /proc/net/packet - oops
Hello, As one of usual tests I run the following script: for i in `find /proc -type f`; do echo -n cat $i /dev/null ... ; cat $i /dev/null; echo done; done This time the culprit is /proc/net/packet. cat process gets killed $ cat /proc/net/packet Segmentation fault and lost in lots of messages from the script but for some reason there is no info in syslog (why?). I could capture the oops only when issued sysrq-7 or grater. That's why I didn't catch the oops earlier. I found it because the bug makes my sparc64 box need a hardware reset most of the time it happens and produces oops 2 screens long. x86 kills the cat process but system is still usable and running fine. Bisection points to: git-ubi.patch GOOD # git-net.patch BAD ipsec-fix-reversed-icmp6-policy-check.patch but this seems to be far from precise :) $ grep ^commit git-net.patch | wc -l 361 Not sure if this is important but when bisecting the mm tree the oops got shorter at some point so maybe some other patch is also involved. This one is from x86: [ 194.508398] BUG: unable to handle kernel paging request at virtual address bd47 [ 194.508412] printing eip: c0135d59 *pde = [ 194.508419] Oops: [#1] PREEMPT [ 194.508424] last sysfs file: /devices/pci:00/:00:01.0/:01:05.0/resource [ 194.508428] Modules linked in: usbhid hid orinoco_cs orinoco hermes pcmcia firmware_class uhci_hcd ehci_hcd usbcore psmouse yenta_socket rsrc_nonstatic rtc 8139too [ 194.508443] [ 194.508447] Pid: 5368, comm: cat Not tainted (2.6.24-rc5 #9) [ 194.508450] EIP: 0060:[c0135d59] EFLAGS: 00210046 CPU: 0 [ 194.508466] EIP is at __lock_acquire+0x5b/0xfc4 [ 194.508469] EAX: 0022 EBX: 00200246 ECX: bd43 EDX: 0002 [ 194.508472] ESI: bd43 EDI: EBP: d816ce80 ESP: d816ce14 [ 194.508475] DS: 007b ES: 007b FS: GS: 0033 SS: 0068 [ 194.508479] Process cat (pid: 5368, ti=d816c000 task=d826a000 task.ti=d816c000) [ 194.508481] Stack: c0135a21 d826a000 d816ce38 c0135697 d826a000 c0146ded [ 194.508490]c1304f98 0002 bd43 0001 d826a000 d816cec0 c013681d [ 194.508498]0006 0003 c03daa08 0001 0044 02ad 0005 [ 194.508506] Call Trace: [ 194.508508] [c01035d8] show_trace_log_lvl+0x1a/0x30 [ 194.508518] [c0103693] show_stack_log_lvl+0xa5/0xca [ 194.508523] [c0103787] show_registers+0xcf/0x23f [ 194.508528] [c0103a04] die+0x10d/0x1f5 [ 194.508532] [c0110cee] do_page_fault+0x27e/0x5f0 [ 194.508540] [c034684a] error_code+0x6a/0x70 [ 194.508550] [c0136d20] lock_acquire+0x5e/0x76 [ 194.508555] [c03461a6] _read_lock+0x35/0x42 [ 194.508560] [c02d957a] sock_i_ino+0x14/0x30 [ 194.508568] [c032c7e8] packet_seq_show+0x19/0xa0 [ 194.508576] [c0179f5c] seq_read+0x19a/0x29e [ 194.508583] [c0191b25] proc_reg_read+0x57/0x78 [ 194.508590] [c0161c8a] vfs_read+0x89/0x11d [ 194.508596] [c0162054] sys_read+0x3d/0x64 [ 194.508600] [c010261a] sysenter_past_esp+0x5f/0xa5 [ 194.508605] === [ 194.508607] Code: c0 85 c0 0f 84 64 03 00 00 9c 58 f6 c4 02 0f 85 b8 07 00 00 83 ff 07 0f 87 de 07 00 00 85 ff 8d 76 00 0f 85 4f 03 00 00 8b 4d c0 8b 71 04 85 f6 0f 84 41 03 00 00 89 f0 e8 d8 d7 ff ff 85 c0 0f [ 194.508651] EIP: [c0135d59] __lock_acquire+0x5b/0xfc4 SS:ESP 0068:d816ce14 [ 194.508660] note: cat[5368] exited with preempt_count 2 .config attached. Regards, Mariusz # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc5 # Sun Dec 16 00:22:27 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y #
Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
Andy Gospodarek [EMAIL PROTECTED] 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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[SNMP]: Fix SNMP counters with PREEMPT
On Sat, Dec 15, 2007 at 06:03:19PM +0100, Eric Dumazet wrote:
How come you change SNMP_INC_STATS_USER() but not SNMP_INC_STATS() ?
Heh, my brain must have blocked me from seeing it because it's
too hard :)
Let's fix it the stupid way first and I'll do a local_t conversion
later.
[SNMP]: Fix SNMP counters with PREEMPT
The SNMP macros use raw_smp_processor_id() in process context
which is illegal because the process may be preempted and then
migrated to another CPU.
This patch makes it use get_cpu/put_cpu to disable preemption.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/snmp.h b/include/net/snmp.h
index 9c5793d..fbb 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -23,6 +23,7 @@
#include linux/cache.h
#include linux/snmp.h
+#include linux/smp.h
/*
* Mibs are stored in array of unsigned long.
@@ -135,14 +136,26 @@ struct linux_mib {
#define SNMP_INC_STATS_BH(mib, field) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())-mibs[field]++)
#define SNMP_INC_STATS_USER(mib, field) \
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_INC_STATS(mib, field) \
- (per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())-mibs[field]++)
+ do { \
+ per_cpu_ptr(mib[!in_softirq()], get_cpu())-mibs[field]++; \
+ put_cpu(); \
+ } while (0)
#define SNMP_DEC_STATS(mib, field) \
- (per_cpu_ptr(mib[!in_softirq()], raw_smp_processor_id())-mibs[field]--)
+ do { \
+ per_cpu_ptr(mib[!in_softirq()], get_cpu())-mibs[field]--; \
+ put_cpu(); \
+ } while (0)
#define SNMP_ADD_STATS_BH(mib, field, addend) \
(per_cpu_ptr(mib[0], raw_smp_processor_id())-mibs[field] += addend)
#define SNMP_ADD_STATS_USER(mib, field, addend)\
- (per_cpu_ptr(mib[1], raw_smp_processor_id())-mibs[field] += addend)
+ do { \
+ per_cpu_ptr(mib[1], get_cpu())-mibs[field] += addend; \
+ put_cpu(); \
+ } while (0)
#endif
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [UDP6]: Counter increment on BH mode
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.
However, an optimisation is indeed possible with some work.
If we can get the address of the per-cpu counter against
some sort of a per-cpu base pointer, e.g., %gs on x86, then
we can do
incq%gs:(%rax)
where %rax would be the offset with %gs as the base. This would
obviate the need for the CPU ID and therefore avoid disabling
preemption.
Hmm, wasn't Christoph working on something like that?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1: cat /proc/net/packet - oops
Mariusz Kozlowski [EMAIL PROTECTED] wrote:
git-ubi.patch
GOOD
#
git-net.patch
BAD
ipsec-fix-reversed-icmp6-policy-check.patch
but this seems to be far from precise :)
I suspect namespace borkage. But just because you pin-pointed
my patch I'll try to track it down :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} - {softirq-on-R} usage.
Andrew Morton [EMAIL PROTECTED] 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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
On Dec 15, 2007 9:27 PM, Herbert Xu [EMAIL PROTECTED] wrote: Andy Gospodarek [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9543] New: RTNL: assertion failed at net/ipv6/addrconf.c (2164)/RTNL: assertion failed at net/ipv4/devinet.c (1055)
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PACKET]: Fix /proc/net/packet crash due to bogus private pointer
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 [EMAIL PROTECTED]
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc5-mm1 -- inconsistent {in-softirq-W} - {softirq-on-R} usage.
On Sat, 15 Dec 2007 15:55:09 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 15, 2007 3:13 PM, Miles Lane [EMAIL PROTECTED] wrote:
On Dec 15, 2007 6:13 AM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 22:58:24 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 14, 2007 6:36 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 14 Dec 2007 17:13:21 -0500
Miles Lane [EMAIL PROTECTED] 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 =
Oops: [#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: fffe
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 0400 c05b74f4 0001 c05b78f4
c048f503 0400 d5a09000 0002 d6267d0c
c01fdf41 d6267d94
db68c04a d6267d74 c012ae81 d6267d94 0028 c05b89f7
00200046
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
Please pull 'fixes-jgarzik' branch of wireless-2.6
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: [EMAIL PROTECTED]
W: ftp://ftp.kernel.org/pub/linux/docs/manpages
S: Maintained
+MARVELL LIBERTAS WIRELESS DRIVER
+P: Dan Williams
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Maintained
+
MARVELL MV643XX ETHERNET DRIVER
P: Dale Farnsworth
M: [EMAIL PROTECTED]
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, 0x);
@@ -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);
-
Re: [PATCH 0/4] [UDP]: memory accounting and limitation (take 10)
From: Hideo AOKI [EMAIL PROTECTED]
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.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Andrew Morton [EMAIL PROTECTED] 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 :-) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETFILTER] xt_hashlimit : speedups hash_dst()
From: Eric Dumazet [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
From: Herbert Xu [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SCTP: Flush fragment queue when exiting partial delivery
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 [EMAIL PROTECTED]
---
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
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.25] SCTP: Use crc32c library for checksum calculations.
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 [EMAIL PROTECTED]
---
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 000..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 [EMAIL PROTECTED]
+ *
+ * Or submit a bug report through the following website:
+ *http://www.sf.net/projects/lksctp
+ *
+ * Written or modified by:
+ *Dinakaran Joseph
+ *Jon Grimm [EMAIL PROTECTED]
+ *Sridhar Samudrala [EMAIL PROTECTED]
+ *
+ * Rewritten to use libcrc32c by:
+ *Vlad Yasevich [EMAIL PROTECTED]
+ *
+ * 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
Re: [patch 2/4] net: use mutex_is_locked() for ASSERT_RTNL()
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip xfrm bug
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
On Sun, 16 Dec 2007 01:37:01 -0500 Miles Lane [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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
(kkkA5ȦFDDF) 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?
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
