Re: [PATCH 1/5] bnx2: Fix rtnl deadlock in bnx2_close

2005-08-24 Thread David S. Miller
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Wed, 24 Aug 2005 11:33:19 -0700 > On Wed, 2005-08-24 at 15:52 -0400, Jeff Garzik wrote: > > > 2) Would prefer to follow the generic net stack and other areas of the > > kernel, for the last piece of quoted code. net stack used to loop on > > sched

Re: [PATCH 1/5] bnx2: Fix rtnl deadlock in bnx2_close

2005-08-24 Thread Michael Chan
On Wed, 2005-08-24 at 15:52 -0400, Jeff Garzik wrote: > Three comments: > > 1) Since you may have to deal with the SMP case, don't you need to add > wmb() or use atomic bit tests? I don't think there will be any nasty races between bnx2_reset_task() and bnx2_close(). If they are racing, the res

Re: [PATCH 1/5] bnx2: Fix rtnl deadlock in bnx2_close

2005-08-24 Thread Jeff Garzik
Michael Chan wrote: This fixes an rtnl deadlock problem when flush_scheduled_work() is called from bnx2_close(). In rare cases, linkwatch_event() may be on the workqueue from a previous close of a different device and it will try to get the rtnl lock which is already held by dev_close(). The fix

[PATCH 1/5] bnx2: Fix rtnl deadlock in bnx2_close

2005-08-24 Thread Michael Chan
This fixes an rtnl deadlock problem when flush_scheduled_work() is called from bnx2_close(). In rare cases, linkwatch_event() may be on the workqueue from a previous close of a different device and it will try to get the rtnl lock which is already held by dev_close(). The fix is to set a flag if w