Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-24 Thread Heiko Carstens
> > Tried to figure out what is causing the delays I experienced when I replaced > > module_init() in af_inet.c with fs_initcall(). After all it turned out that > > synchronize_net() which is basicically nothing else than synchronize_rcu() > > sometimes takes several seconds to complete?! No idea w

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-20 Thread Heiko Carstens
> > As spinlock debugging still does not work with the qeth driver I > > want to pick up the discussion. > > Does something like the patch below work? > > But this all begs the question, what happens if you want to > dig into the internals of a protocol which is built modular and > hasn't been lo

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-19 Thread David S. Miller
From: Christian Borntraeger <[EMAIL PROTECTED]> Date: Wed, 19 Apr 2006 12:45:48 +0200 > As spinlock debugging still does not work with the qeth driver I > want to pick up the discussion. Does something like the patch below work? But this all begs the question, what happens if you want to dig int

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-19 Thread Christian Borntraeger
As spinlock debugging still does not work with the qeth driver I want to pick up the discussion. On Saturday 08 April 2006 12:12, Andrew Morton wrote: > Heiko Carstens <[EMAIL PROTECTED]> wrote: [...] > > -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) > > +vmlinux-main := $(core-y)

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-15 Thread Heiko Carstens
> > callchain: inet_init() -> inet_register_protosw() -> synchronize_net() > > The problem can't be rcu_init(), that gets done very early > in init/main.c > > Maybe it's some timer or something else specific to s390? > > It could also be that there's perhaps nothing to context > switch to, thus

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-15 Thread David S. Miller
From: Heiko Carstens <[EMAIL PROTECTED]> Date: Sat, 15 Apr 2006 09:27:45 +0200 > Tried to figure out what is causing the delays I experienced when I replaced > module_init() in af_inet.c with fs_initcall(). After all it turned out that > synchronize_net() which is basicically nothing else than syn

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-15 Thread Heiko Carstens
> > Ok, so the problem seems to be that inet_init gets called after qeth_init. > > Looking at the top level Makefile this seems to be true for all network > > drivers in drivers/net/ and drivers/s390/net/ since we have > > > > vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) > > > > The

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-08 Thread Sam Ravnborg
On Sat, Apr 08, 2006 at 03:14:04AM -0700, David S. Miller wrote: > Perhaps fs_initcall() would work better. Or if that causes > problems we could create a net_initcall() that sits between > fs_initcall() and device_initcall(). fs_initcall() seems to be used mainly for "init after subsystem" stu

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-08 Thread Heiko Carstens
> We could make inet_init() a subsystem init but I vaguely recall > that we were doing that at one point and it broke things for > some reason. > > Perhaps fs_initcall() would work better. Or if that causes > problems we could create a net_initcall() that sits between > fs_initcall() and device_i

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-08 Thread Andrew Morton
Heiko Carstens <[EMAIL PROTECTED]> wrote: > > Ok, so the problem seems to be that inet_init gets called after qeth_init. > Looking at the top level Makefile this seems to be true for all network > drivers in drivers/net/ and drivers/s390/net/ since we have > > vmlinux-main := $(core-y) $(libs-y

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-08 Thread David S. Miller
From: Heiko Carstens <[EMAIL PROTECTED]> Date: Sat, 8 Apr 2006 12:02:13 +0200 > Ok, so the problem seems to be that inet_init gets called after qeth_init. > Looking at the top level Makefile this seems to be true for all network > drivers in drivers/net/ and drivers/s390/net/ since we have > > vm

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-08 Thread Heiko Carstens
> > The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK > > detects that this lock is not initialized as it is supposed to be. > > This is a initialization order problem then, because: > arp_init > neigh_table_init > rwlock_init > > does the initial

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-07 Thread David S. Miller
From: Heiko Carstens <[EMAIL PROTECTED]> Date: Fri, 7 Apr 2006 10:15:33 +0200 > From: Heiko Carstens <[EMAIL PROTECTED]> > > The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK > detects that this lock is not initialized as it is supposed to be. > > Signed-off-by: Heiko Carst

Re: [patch] ipv4: initialize arp_tbl rw lock

2006-04-07 Thread Stephen Hemminger
On Fri, 7 Apr 2006 10:15:33 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote: > From: Heiko Carstens <[EMAIL PROTECTED]> > > The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK > detects that this lock is not initialized as it is supposed to be. > > Signed-off-by: Heiko Carsten

[patch] ipv4: initialize arp_tbl rw lock

2006-04-07 Thread Heiko Carstens
From: Heiko Carstens <[EMAIL PROTECTED]> The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK detects that this lock is not initialized as it is supposed to be. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- net/ipv4/arp.c |1 + 1 file changed, 1 insertion(+) diff