* (no subject) [not found] <PAO-EX01Cv3uS7sBdxk00001183@pao-ex01.pao.digeo.com> @ 2003-05-16 0:53 ` David S. Miller 2003-05-16 1:12 ` [2.5.69] rtnl-deadlock with usermodehelper and keventd Andrew Morton 0 siblings, 1 reply; 10+ messages in thread From: David S. Miller @ 2003-05-16 0:53 UTC (permalink / raw) To: akpm; +Cc: lists, linux-kernel, jt Way too invasive, and this adds bugs to the ipmr.c code. I'd much rather see /sbin/hotplug be able to handle things asynchonously. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-16 0:53 ` David S. Miller @ 2003-05-16 1:12 ` Andrew Morton 2003-05-16 1:27 ` Jean Tourrilhes 2003-05-23 7:06 ` Martin Diehl 0 siblings, 2 replies; 10+ messages in thread From: Andrew Morton @ 2003-05-16 1:12 UTC (permalink / raw) To: David S. Miller; +Cc: lists, linux-kernel, jt "David S. Miller" <davem@redhat.com> wrote: > > > Way too invasive, and this adds bugs to the ipmr.c code. Thought you'd say that. My mail client munched the context. For reference: > Martin Diehl <lists@mdiehl.de> wrote: > > > > > > [ unregister_netdevice calls call_usermodehelper which waits for keventd to > > pick up the subprocess_info, but keventd is blocked on rtnl_lock, which > > unregister_netdev took ] > > > > The nice way to fix this is to change unregister_netdev so it runs > net_run_sbin_hotplug() outside rtnl_lock. > > Problem is, it's hard. I just knocked up the below patch, and it still > needs work. Mainly because of the tremendously deep codepaths which call > unregister_netdevice(), knowing that they are under rtnl_lock(). > > It would be nice to clean all that up, and this patch actually contains > good cleanups and a couple of bugfixes. But I don't think it's going to > get there. > > > The other way to fix it is to make call_usermodehelper() more async. That > means kmallocing the sub_info, the work struct and the string arrays and > all the strings. This is more general, and will probably fix other > keventd-related deadlocks. But it is unattractive. > > > Or we could change linkwatch to not take rtnl_lock() by some means. That's > even less general. > > > David, any comments? You think the below approach shuld be pursued? "David S. Miller" <davem@redhat.com> wrote: > > I'd much rather see /sbin/hotplug be able to handle things > asynchonously. Yeah, I'm inclined to agree. I'll take a look at it. Meanwhile please take a look at the leftover cleanups. It fixes a bug in drivers/net/hamradio/dmascc.c too. 25-akpm/drivers/net/hamradio/dmascc.c | 4 +--- 25-akpm/drivers/net/irda/ali-ircc.c | 7 ++----- 25-akpm/drivers/net/irda/donauboe.c | 7 +------ 25-akpm/drivers/net/irda/irda-usb.c | 10 ++++------ 25-akpm/drivers/net/irda/irport.c | 7 ++----- 25-akpm/drivers/net/irda/irtty.c | 7 ++----- 25-akpm/drivers/net/irda/nsc-ircc.c | 7 ++----- 25-akpm/drivers/net/irda/sa1100_ir.c | 7 ++----- 25-akpm/drivers/net/irda/toshoboe.c | 8 ++------ 25-akpm/drivers/net/irda/w83977af_ir.c | 7 ++----- 10 files changed, 20 insertions(+), 51 deletions(-) diff -puN drivers/net/hamradio/dmascc.c~unregister_netdev-cleanup drivers/net/hamradio/dmascc.c --- 25/drivers/net/hamradio/dmascc.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/hamradio/dmascc.c Thu May 15 18:05:29 2003 @@ -325,9 +325,7 @@ void cleanup_module(void) { /* Unregister devices */ for (i = 0; i < 2; i++) { if (info->dev[i].name) - rtnl_lock(); - unregister_netdevice(&info->dev[i]); - rtnl_unlock(); + unregister_netdev(&info->dev[i]); } /* Reset board */ diff -puN drivers/net/irda/ali-ircc.c~unregister_netdev-cleanup drivers/net/irda/ali-ircc.c --- 25/drivers/net/irda/ali-ircc.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/ali-ircc.c Thu May 15 18:05:29 2003 @@ -390,11 +390,8 @@ static int __exit ali_ircc_close(struct iobase = self->io.fir_base; /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); /* Release the PORT that this driver is using */ IRDA_DEBUG(4, "%s(), Releasing Region %03x\n", __FUNCTION__, self->io.fir_base); diff -puN drivers/net/irda/donauboe.c~unregister_netdev-cleanup drivers/net/irda/donauboe.c --- 25/drivers/net/irda/donauboe.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/donauboe.c Thu May 15 18:05:29 2003 @@ -1577,12 +1577,7 @@ toshoboe_close (struct pci_dev *pci_dev) } if (self->netdev) - { - /* Remove netdevice */ - rtnl_lock (); - unregister_netdevice (self->netdev); - rtnl_unlock (); - } + unregister_netdev(self->netdev); kfree (self->ringbuf); self->ringbuf = NULL; diff -puN drivers/net/irda/irda-usb.c~unregister_netdev-cleanup drivers/net/irda/irda-usb.c --- 25/drivers/net/irda/irda-usb.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/irda-usb.c Thu May 15 18:05:29 2003 @@ -1231,12 +1231,10 @@ static inline int irda_usb_close(struct ASSERT(self != NULL, return -1;); /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - self->netdev = NULL; - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); + self->netdev = NULL; + /* Remove the speed buffer */ if (self->speed_buff != NULL) { kfree(self->speed_buff); diff -puN drivers/net/irda/irport.c~unregister_netdev-cleanup drivers/net/irda/irport.c --- 25/drivers/net/irda/irport.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/irport.c Thu May 15 18:05:29 2003 @@ -256,11 +256,8 @@ int irport_close(struct irport_cb *self) self->dongle = NULL; /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); /* Release the IO-port that this driver is using */ IRDA_DEBUG(0 , "%s(), Releasing Region %03x\n", diff -puN drivers/net/irda/irtty.c~unregister_netdev-cleanup drivers/net/irda/irtty.c --- 25/drivers/net/irda/irtty.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/irtty.c Thu May 15 18:05:29 2003 @@ -282,11 +282,8 @@ static void irtty_close(struct tty_struc self->dongle = NULL; /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); self = hashbin_remove(irtty, (int) self, NULL); diff -puN drivers/net/irda/nsc-ircc.c~unregister_netdev-cleanup drivers/net/irda/nsc-ircc.c --- 25/drivers/net/irda/nsc-ircc.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/nsc-ircc.c Thu May 15 18:05:29 2003 @@ -391,11 +391,8 @@ static int __exit nsc_ircc_close(struct iobase = self->io.fir_base; /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); /* Release the PORT that this driver is using */ IRDA_DEBUG(4, "%s(), Releasing Region %03x\n", diff -puN drivers/net/irda/sa1100_ir.c~unregister_netdev-cleanup drivers/net/irda/sa1100_ir.c --- 25/drivers/net/irda/sa1100_ir.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/sa1100_ir.c Thu May 15 18:05:29 2003 @@ -1122,11 +1122,8 @@ static void __exit sa1100_irda_exit(void { struct net_device *dev = dev_get_drvdata(&sa1100ir_device.dev); - if (dev) { - rtnl_lock(); - unregister_netdevice(dev); - rtnl_unlock(); - } + if (dev) + unregister_netdev(dev); sys_device_unregister(&sa1100ir_device); driver_unregister(&sa1100ir_driver); diff -puN drivers/net/irda/toshoboe.c~unregister_netdev-cleanup drivers/net/irda/toshoboe.c --- 25/drivers/net/irda/toshoboe.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/toshoboe.c Thu May 15 18:05:29 2003 @@ -679,12 +679,8 @@ toshoboe_remove (struct pci_dev *pci_dev self->recv_bufs[i] = NULL; } - if (self->netdev) { - /* Remove netdevice */ - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); kfree (self->taskfilebuf); self->taskfilebuf = NULL; diff -puN drivers/net/irda/w83977af_ir.c~unregister_netdev-cleanup drivers/net/irda/w83977af_ir.c --- 25/drivers/net/irda/w83977af_ir.c~unregister_netdev-cleanup Thu May 15 18:05:29 2003 +++ 25-akpm/drivers/net/irda/w83977af_ir.c Thu May 15 18:05:29 2003 @@ -299,11 +299,8 @@ static int w83977af_close(struct w83977a #endif /* CONFIG_USE_W977_PNP */ /* Remove netdevice */ - if (self->netdev) { - rtnl_lock(); - unregister_netdevice(self->netdev); - rtnl_unlock(); - } + if (self->netdev) + unregister_netdev(self->netdev); /* Release the PORT that this driver is using */ IRDA_DEBUG(0 , "%s(), Releasing Region %03x\n", _ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-16 1:12 ` [2.5.69] rtnl-deadlock with usermodehelper and keventd Andrew Morton @ 2003-05-16 1:27 ` Jean Tourrilhes 2003-05-23 7:06 ` Martin Diehl 1 sibling, 0 replies; 10+ messages in thread From: Jean Tourrilhes @ 2003-05-16 1:27 UTC (permalink / raw) To: Andrew Morton; +Cc: David S. Miller, linux-kernel On Thu, May 15, 2003 at 06:12:11PM -0700, Andrew Morton wrote: > > Meanwhile please take a look at the leftover cleanups. It fixes a bug in > drivers/net/hamradio/dmascc.c too. > > > 25-akpm/drivers/net/hamradio/dmascc.c | 4 +--- > 25-akpm/drivers/net/irda/ali-ircc.c | 7 ++----- > 25-akpm/drivers/net/irda/donauboe.c | 7 +------ > 25-akpm/drivers/net/irda/irda-usb.c | 10 ++++------ > 25-akpm/drivers/net/irda/irport.c | 7 ++----- > 25-akpm/drivers/net/irda/irtty.c | 7 ++----- > 25-akpm/drivers/net/irda/nsc-ircc.c | 7 ++----- > 25-akpm/drivers/net/irda/sa1100_ir.c | 7 ++----- > 25-akpm/drivers/net/irda/toshoboe.c | 8 ++------ > 25-akpm/drivers/net/irda/w83977af_ir.c | 7 ++----- > 10 files changed, 20 insertions(+), 51 deletions(-) IrDA part of the patch applied and compiled fine here (I was worried of header issues). And this doesn't conflict with the patches I sent to Jeff ;-) I'll add that in my patch queue, just in case ;-) Thanks... Jean ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-16 1:12 ` [2.5.69] rtnl-deadlock with usermodehelper and keventd Andrew Morton 2003-05-16 1:27 ` Jean Tourrilhes @ 2003-05-23 7:06 ` Martin Diehl 2003-05-23 6:59 ` David S. Miller 1 sibling, 1 reply; 10+ messages in thread From: Martin Diehl @ 2003-05-23 7:06 UTC (permalink / raw) To: Andrew Morton; +Cc: David S. Miller, Greg KH, linux-kernel, Jean Tourrilhes On Thu, 15 May 2003, Andrew Morton wrote: > > > [ unregister_netdevice calls call_usermodehelper which waits for keventd to > > > pick up the subprocess_info, but keventd is blocked on rtnl_lock, which > > > unregister_netdev took ] > > > "David S. Miller" <davem@redhat.com> wrote: > > > > I'd much rather see /sbin/hotplug be able to handle things > > asynchonously. > > Yeah, I'm inclined to agree. I'll take a look at it. Asking just because there was another user hitting this deadlock: it seems with linux-irda we have a very good test case for reproducing this issue. So I'd be happy to go testing patches if this might help. I've also looked into the code to see if I could do something myself. Well, personally I do also think the best way would be to modify the kernel hotplug part so we can call it asynch under rtnl-lock. Unfortunately, given the fact there are already several layers (schedule_work, 2 times kernel_thread and execve) stacked on top of each other, I'm pretty much lost how to fix it without breaking other stuff. I was also thinking about making net_run_sbin_hotplug asynch itself, but I'm unsure how this might interact with call_usermodehelper(), namely wrt. the wait=0 parameter. I assume we all agree this issue isn't easy to resolve. May I suggest adding it to the must-fix-before-2.6 list so it wouldn't get lost? As people tend to run with CONFIG_HOTPLUG=y there would be a lot of trouble with 2.6 otherwise. Thanks. Martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 7:06 ` Martin Diehl @ 2003-05-23 6:59 ` David S. Miller 2003-05-23 9:38 ` Martin Diehl 0 siblings, 1 reply; 10+ messages in thread From: David S. Miller @ 2003-05-23 6:59 UTC (permalink / raw) To: lists; +Cc: akpm, greg, linux-kernel, jt From: Martin Diehl <lists@mdiehl.de> Date: Fri, 23 May 2003 09:06:10 +0200 (CEST) Asking just because there was another user hitting this deadlock: It's fixed in current 2.5.x sources, wake up :-) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 6:59 ` David S. Miller @ 2003-05-23 9:38 ` Martin Diehl 2003-05-23 9:43 ` David S. Miller 0 siblings, 1 reply; 10+ messages in thread From: Martin Diehl @ 2003-05-23 9:38 UTC (permalink / raw) To: David S. Miller; +Cc: akpm, Greg KH, linux-kernel, Jean Tourrilhes On Thu, 22 May 2003, David S. Miller wrote: > Asking just because there was another user hitting this deadlock: > > It's fixed in current 2.5.x sources, wake up :-) Oops, sorry for the noise, I hadn't noticed this yet. But nope, unfortunately it's still hanging! I've just tested with 2.5.69-bk15. Running into the same deadlock due to sleeping with rtnl hold. This time however it seems it's triggered from sysfs side! Thanks anyway! Martin ------------------------- May 23 11:07:31 srv kernel: events/0 D C02B05DC 4294946908 4 1 5 3 (L-TLB) May 23 11:07:31 srv kernel: Call Trace: May 23 11:07:31 srv kernel: [__down+197/368] __down+0xc5/0x170 May 23 11:07:31 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:31 srv kernel: [__down_failed+8/12] __down_failed+0x8/0xc May 23 11:07:31 srv kernel: [.text.lock.rtnetlink+5/94] .text.lock.rtnetlink+0x5/0x5e May 23 11:07:31 srv kernel: [linkwatch_event+33/48] linkwatch_event+0x21/0x30 May 23 11:07:32 srv kernel: [worker_thread+478/752] worker_thread+0x1de/0x2f0 May 23 11:07:32 srv kernel: [linkwatch_event+0/48] linkwatch_event+0x0/0x30 May 23 11:07:32 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:32 srv kernel: [ret_from_fork+6/32] ret_from_fork+0x6/0x20 May 23 11:07:32 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:32 srv kernel: [worker_thread+0/752] worker_thread+0x0/0x2f0 May 23 11:07:32 srv kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 May 23 11:07:32 srv kernel: irattach D 00000000 19710128 2109 1 2104 (NOTLB) May 23 11:07:32 srv kernel: Call Trace: May 23 11:07:32 srv kernel: [wait_for_completion+220/352] wait_for_completion+0xdc/0x160 May 23 11:07:32 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:32 srv kernel: [__wake_up+83/144] __wake_up+0x53/0x90 May 23 11:07:32 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:32 srv kernel: [call_usermodehelper+290/301] call_usermodehelper+0x122/0x12d May 23 11:07:32 srv kernel: [__call_usermodehelper+0/96] __call_usermodehelper+0x0/0x60 May 23 11:07:32 srv kernel: [__call_usermodehelper+0/96] __call_usermodehelper+0x0/0x60 May 23 11:07:32 srv kernel: [sprintf+18/32] sprintf+0x12/0x20 May 23 11:07:32 srv kernel: [kset_hotplug+419/464] kset_hotplug+0x1a3/0x1d0 May 23 11:07:32 srv kernel: [kobject_del+75/96] kobject_del+0x4b/0x60 May 23 11:07:32 srv kernel: [class_device_del+166/192] class_device_del+0xa6/0xc0 May 23 11:07:32 srv kernel: [class_device_unregister+11/32] class_device_unregister+0xb/0x20 May 23 11:07:32 srv kernel: [unregister_netdevice+356/496] unregister_netdevice+0x164/0x1f0 May 23 11:07:32 srv kernel: [unregister_netdev+16/48] unregister_netdev+0x10/0x30 May 23 11:07:32 srv kernel: [_end+206658744/1070163436] +0x128/0x75c [sir_dev] May 23 11:07:32 srv kernel: [_end+206653994/1070163436] sirdev_put_instance+0xfe/0x110 [sir_dev] May 23 11:07:32 srv kernel: [tty_wait_until_sent+235/256] tty_wait_until_sent+0xeb/0x100 May 23 11:07:32 srv kernel: [_end+206513126/1070163436] irtty_close+0x3a/0x141 [irtty_sir] May 23 11:07:32 srv kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 May 23 11:07:32 srv kernel: [tty_set_ldisc+205/464] tty_set_ldisc+0xcd/0x1d0 May 23 11:07:32 srv kernel: [serial8250_tx_empty+60/128] serial8250_tx_empty+0x3c/0x80 May 23 11:07:32 srv kernel: [uart_wait_until_sent+150/224] uart_wait_until_sent+0x96/0xe0 May 23 11:07:32 srv kernel: [_end+206514243/1070163436] +0x274/0x31d [irtty_sir] May 23 11:07:32 srv kernel: [_end+206512540/1070163436] irtty_open+0x0/0x210 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206513068/1070163436] irtty_close+0x0/0x141 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206511964/1070163436] irtty_ioctl+0x0/0x240 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206510924/1070163436] irtty_receive_buf+0x0/0xb0 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206511100/1070163436] irtty_receive_room+0x0/0x30 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206511148/1070163436] irtty_write_wakeup+0x0/0x40 [irtty_sir] May 23 11:07:32 srv kernel: [_end+206517164/1070163436] +0x0/0x100 [irtty_sir] May 23 11:07:32 srv kernel: [dput+28/608] dput+0x1c/0x260 May 23 11:07:32 srv kernel: [tty_ioctl+888/1152] tty_ioctl+0x378/0x480 May 23 11:07:32 srv kernel: [sys_ioctl+646/744] sys_ioctl+0x286/0x2e8 May 23 11:07:32 srv kernel: [sys_fcntl64+89/112] sys_fcntl64+0x59/0x70 May 23 11:07:32 srv kernel: [sys_fcntl64+101/112] sys_fcntl64+0x65/0x70 May 23 11:07:32 srv kernel: [syscall_call+7/11] syscall_call+0x7/0xb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 9:38 ` Martin Diehl @ 2003-05-23 9:43 ` David S. Miller 2003-05-23 14:42 ` Stian Jordet ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: David S. Miller @ 2003-05-23 9:43 UTC (permalink / raw) To: lists; +Cc: akpm, greg, linux-kernel, jt, shemminger From: Martin Diehl <lists@mdiehl.de> Date: Fri, 23 May 2003 11:38:38 +0200 (CEST) On Thu, 22 May 2003, David S. Miller wrote: > Asking just because there was another user hitting this deadlock: > > It's fixed in current 2.5.x sources, wake up :-) Oops, sorry for the noise, I hadn't noticed this yet. But nope, unfortunately it's still hanging! I've just tested with 2.5.69-bk15. Running into the same deadlock due to sleeping with rtnl hold. This time however it seems it's triggered from sysfs side! Stephen, you need to do the device class stuff outside of the RTNL lock please. At least I didn't add this bug :-) This should fix it. --- net/core/dev.c.~1~ Fri May 23 02:42:37 2003 +++ net/core/dev.c Fri May 23 02:43:20 2003 @@ -2754,6 +2754,8 @@ dev->next = NULL; + netdev_unregister_sysfs(dev); + netdev_wait_allrefs(dev); BUG_ON(atomic_read(&dev->refcnt)); @@ -2841,8 +2843,6 @@ BUG_TRAP(!dev->master); free_divert_blk(dev); - - netdev_unregister_sysfs(dev); spin_lock(&unregister_todo_lock); dev->next = unregister_todo; ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 9:43 ` David S. Miller @ 2003-05-23 14:42 ` Stian Jordet 2003-05-23 16:46 ` Jean Tourrilhes 2003-05-23 23:25 ` Martin Diehl 2 siblings, 0 replies; 10+ messages in thread From: Stian Jordet @ 2003-05-23 14:42 UTC (permalink / raw) To: David S. Miller; +Cc: lists, akpm, greg, linux-kernel, jt, shemminger fre, 23.05.2003 kl. 11.43 skrev David S. Miller: > From: Martin Diehl <lists@mdiehl.de> > Date: Fri, 23 May 2003 11:38:38 +0200 (CEST) > > On Thu, 22 May 2003, David S. Miller wrote: > > > Asking just because there was another user hitting this deadlock: > > > > It's fixed in current 2.5.x sources, wake up :-) > > Oops, sorry for the noise, I hadn't noticed this yet. > > But nope, unfortunately it's still hanging! I've just tested with > 2.5.69-bk15. Running into the same deadlock due to sleeping with rtnl > hold. This time however it seems it's triggered from sysfs side! > > Stephen, you need to do the device class stuff outside of the RTNL > lock please. > > At least I didn't add this bug :-) > > This should fix it. And so it did :-) Thanks. Best regards, Stian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 9:43 ` David S. Miller 2003-05-23 14:42 ` Stian Jordet @ 2003-05-23 16:46 ` Jean Tourrilhes 2003-05-23 23:25 ` Martin Diehl 2 siblings, 0 replies; 10+ messages in thread From: Jean Tourrilhes @ 2003-05-23 16:46 UTC (permalink / raw) To: David S. Miller; +Cc: lists, akpm, greg, linux-kernel, jt, shemminger On Fri, May 23, 2003 at 02:43:08AM -0700, David S. Miller wrote: > From: Martin Diehl <lists@mdiehl.de> > Date: Fri, 23 May 2003 11:38:38 +0200 (CEST) > > On Thu, 22 May 2003, David S. Miller wrote: > > > Asking just because there was another user hitting this deadlock: > > > > It's fixed in current 2.5.x sources, wake up :-) > > Oops, sorry for the noise, I hadn't noticed this yet. > > But nope, unfortunately it's still hanging! I've just tested with > 2.5.69-bk15. Running into the same deadlock due to sleeping with rtnl > hold. This time however it seems it's triggered from sysfs side! > > Stephen, you need to do the device class stuff outside of the RTNL > lock please. > > At least I didn't add this bug :-) > > This should fix it. Thanks Dave, we are very much obliged ! Jean ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [2.5.69] rtnl-deadlock with usermodehelper and keventd 2003-05-23 9:43 ` David S. Miller 2003-05-23 14:42 ` Stian Jordet 2003-05-23 16:46 ` Jean Tourrilhes @ 2003-05-23 23:25 ` Martin Diehl 2 siblings, 0 replies; 10+ messages in thread From: Martin Diehl @ 2003-05-23 23:25 UTC (permalink / raw) To: David S. Miller; +Cc: akpm, Greg KH, linux-kernel, Jean Tourrilhes, shemminger On Fri, 23 May 2003, David S. Miller wrote: > But nope, unfortunately it's still hanging! I've just tested with > 2.5.69-bk15. Running into the same deadlock due to sleeping with rtnl > hold. This time however it seems it's triggered from sysfs side! > > Stephen, you need to do the device class stuff outside of the RTNL > lock please. > > At least I didn't add this bug :-) > > This should fix it. Well, back online now pretty late ;-) Yes, as was already reported I can also confirm from testing the deadlock is gone now. Thanks for resolving this issue! Just a minor question before the thread gets closed: Don't we have the same problem in the register path? register_netdevice is running unter rtnl and calls netdev_register_sysfs. I've never seen a deadlock there, but I'd expect this to sleep for hotplug usermode completion as well. Maybe this is just what you meant by your comment above ;-) Martin ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-05-23 23:05 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <PAO-EX01Cv3uS7sBdxk00001183@pao-ex01.pao.digeo.com>
2003-05-16 0:53 ` David S. Miller
2003-05-16 1:12 ` [2.5.69] rtnl-deadlock with usermodehelper and keventd Andrew Morton
2003-05-16 1:27 ` Jean Tourrilhes
2003-05-23 7:06 ` Martin Diehl
2003-05-23 6:59 ` David S. Miller
2003-05-23 9:38 ` Martin Diehl
2003-05-23 9:43 ` David S. Miller
2003-05-23 14:42 ` Stian Jordet
2003-05-23 16:46 ` Jean Tourrilhes
2003-05-23 23:25 ` Martin Diehl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox