Date: Mon, 15 Jan 2001 23:22:51 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Bosko Milekic <bmilekic@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <20010115232251.Q7240@fw.wintelcom.net> In-Reply-To: <XFMail.010115230822.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Mon, Jan 15, 2001 at 11:08:22PM -0800 References: <20010115224043.M7240@fw.wintelcom.net> <XFMail.010115230822.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@FreeBSD.org> [010115 23:08] wrote: > > On 16-Jan-01 Alfred Perlstein wrote: > > * Bosko Milekic <bmilekic@FreeBSD.org> [010115 17:53] wrote: > >> bmilekic 2001/01/15 17:53:13 PST > >> > >> Modified files: > >> sys/kern uipc_mbuf.c > >> Log: > >> Add some KASSERTs valid if WITNESS is defined to verify that the mbuf > >> allocation routines are being called safely. Since we drop our relevant > >> mbuf mutex and acquire Giant before we call kmem_malloc(), we have > >> to make sure that this does not pave the way for a fatal lock order > >> reversal. Check that either Giant is already held (in which case it's safe > >> to grab it again and recurse on it) or, if Giant is not held, that no > >> other locks are held before we try to acquire Giant. > >> > >> Similarily, add a KASSERT valid in the WITNESS case in m_reclaim() to > >> nail callers who end up in m_reclaim() and hold a lock. > > > > I think I may be missing something obvious here, but I'd like to > > understand what's going on here better. > > > > Doesn't this just guarantee a panic if we need to kmem_alloc while > > the driver lock is held and WITNESS is enabled? I don't see how > > this prevents/fixes anything ATM, if kmem_alloc is called (hence > > requiring Giant) we either panic, or have a chance of deadlocking. > > > > One of the ways to fix this would be to identify the entry points > > from the top half of the kernel and surround the function bodies > > with DROP_GIANT (ick) for the time being in order to fix the lock > > order before aquiring the driver lock. > > Right now all network drivers are not MP safe, so they all get Giant first > thing, so you won't hit this. Same for all syscalls (or all the ones hitting > network code at least) so this will always be a recursion. When drivers are > marked as MP safe, then the locking will have to be fixed such that they don't > call into mbuf allocation with their lock held if they can help it. Ok, then what were the panic's you and Jake were discussing on IRC related to? I thought it was directly related to the out of order locking on the driverlock. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010115232251.Q7240>