Date: Thu, 10 Apr 2003 15:12:43 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Jeffrey Hsu <hsu@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: LOR in if_detach Message-ID: <20030410150609.U1863@beagle.fokus.fraunhofer.de> In-Reply-To: <200304101251.h3ACphHo021011@mta7.pltn13.pbi.net> References: <200304101251.h3ACphHo021011@mta7.pltn13.pbi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Apr 2003, Jeffrey Hsu wrote: JH> > I must stop the interface before calling if_detach. JH> JH>The midway driver doesn't do that now anyways, so there's no reason to JH>start now. I have rewritten the midway driver for busdma, to use (more or less correct) locking and build as a module. You must stop the interface in that case to free resource and to ensure, that it has stopped dma-ing. JH> > If I unlock after stoping before detaching, I get a race window JH> > where somebody could just UP the interface. JH> JH>This race is outside the scope of the network driver lock. So what mechanism ensures, that my exported functions (ioctl, start, init) are not called while I'm detaching? Is there such a mechanism or not? JH> > While thinking about, it seems, that having a lock in struct ifnet would JH> > make sense in the long run. How can we otherwise ensure, that nobody is JH> > calling if_ioctl while we are detaching the interface? JH> JH>That's what I had planned. What would that lock do? I mean, which, if any, of the exported driver functions would be called with that lock held? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410150609.U1863>