Alexey,
> > Please explain to me why do we have to hold rtnl lock while sleeping in
> > unregister_netdevice ?
>
>... not "while sleeping", but just "while".
>
>If the lock would be for the device, it would be local to the device,
>rather than global. The semaphore blocks all the networking configuration
>until caller will complete stuff related to unregistering.
>
>Forward references from the unregistered device under cannot be invalidated
>before the device is unregistered. All such work is done after unregistry
>for "old style" or in dev->uninit/destructor hooks, which are used
>by "new style" devices.
All I'm saying is that. Unregistration is effectively complete at the time
we call schedule(). At this point only, so to speak, buggy subsystems are
holding references. Adding new devices and routes won't hurt. Even if
it will only those buggy guys might have problems with that.
> > 1 - Something is not releasing device
>
>Let's find this something! It witnesses about really serious bug.
>
>I cannot reproduce this too. Understand, please, we _can_ follow
>your proposal, all 100% of old style devices do not need uninit in real
>life. But then we never will find the bug. You cannot reproduce it,
>I cannot too.
I'm not following you. How dropping rtnl_lock while calling schedule()
would affect
our bug hunting :) ?
We still emit "waiting for ..." warning message and we still don't give
control
to the driver unless refcount is 0.
> > fix it. If one thing is buggy it doesn't mean
>It means exactly this. Kernel panic would be even better, if it was
>possible to detect deadlock reliably.
There is no deadlock here.
Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:37 EST