Date: Wed, 31 Aug 2011 10:59:11 -0600 From: Warner Losh <imp@bsdimp.com> To: Andriy Gapon <avg@freebsd.org> Cc: Hans Petter Selasky <hselasky@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: skipping locks, mutex_owned, usb Message-ID: <B230DCD7-E21F-4B66-9ECE-B759BEBBB749@bsdimp.com> In-Reply-To: <4E5E655E.8060505@FreeBSD.org> References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> <DD9206EC-A969-434A-ABC5-15B2857C571C@bsdimp.com> <4E5E655E.8060505@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 31, 2011, at 10:46 AM, Andriy Gapon wrote: > on 31/08/2011 19:32 Warner Losh said the following: >>=20 >> On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: >>> So why the mutex unwinding/rewinding code is present at all? >>> What kind of situations is it supposed to prevent? >>>=20 >>> Personally I think that we either know that those drivers should not = hold the >>> locks in question (bus_mtx and xfer_mtx) or we know that they hold = them. >>> I do not see why we have to be conditional here or have a loop = even... >>=20 >> Today, I think we know these things. In the past, as the code was = written, there was a lot more special case code needed for giant = cohabitation. >=20 > Since you chimed in... :-) > I have a hard time imagining a situation where that code is useful = today or was > useful before. > Any example, purely hypothetical even, would do. IIRC, and Hans can correct me, this code was put in so that we could run = GIANT locked usb network drivers (or was it TTY drivers). There were = situations where the USB would have a lock held, then need to call into = code that picked up GIANT which then called back into the USB stack = which then would pick up GIANT and make calls to routines to pickup the = USB lock, and fail due to recursion (or was that to prevent a witness = warning about sleeping with malloc, it has been a while and I don't = recall for sure). I'm sure I'm forgetting a detail or two because = re-reading what I just wrote makes me go "what, that doesn't sound quite = right" :) Today, the locking landscape is such that I don't think we still have = the same issues. However, I've not studied the USB code recently, so = hopefully Hans can help sort out the reasons for it. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B230DCD7-E21F-4B66-9ECE-B759BEBBB749>