Date: Wed, 03 Dec 2014 10:21:01 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: freebsd-current@freebsd.org, Warner Losh <imp@bsdimp.com>, Andriy Gapon <avg@freebsd.org> Subject: Re: witness and modules. Message-ID: <1758681.vj4zSF7cnf@ralph.baldwin.cx> In-Reply-To: <547F15D0.8050009@freebsd.org> References: <54788FF3.3030602@freebsd.org> <547EF378.8090202@FreeBSD.org> <547F15D0.8050009@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, December 03, 2014 09:53:20 PM Julian Elischer wrote: > On 12/3/14, 7:26 PM, Andriy Gapon wrote: > > On 03/12/2014 04:33, Julian Elischer wrote: > >> On 12/3/14, 12:24 AM, Warner Losh wrote: > >>>> On Dec 1, 2014, at 10:08 PM, Julian Elischer <julian@freebsd.org= > > >>>> wrote: > >>>>=20 > >>>> On 12/1/14, 11:39 PM, John Baldwin wrote: > >>>>> On Friday, November 28, 2014 11:08:35 PM Julian Elischer wrote:= > >>>>>> Do we need to compile all modules with witness definitions whe= n > >>>>>> linking with a kernel compiled with witness? > >>>>>> This was true at one stage but I remember some work was done t= o make > >>>>>> them compatible. > >>>>>=20 > >>>>> You should not need this. modules always call functions in the= kernel > >>>>> for > >>>>> lock operations and this functions are what invoke WITNESS. > >>>>=20 > >>>> that's what I thought but empirical evidence disagrees. > >>>> I'll try some more cases. > >>>=20 > >>> I swap back and forth all the time between the two. Kernel module= s don=E2=80=99t > >>> change when you compile them with WITNESS or without. > >>=20 > >> not entirely.. > >> hwpmc.ko: U witness_restore > >> hwpmc.ko: U witness_save > >> zfs.ko: U witness_restore > >> zfs.ko: U witness_save > >=20 > > Seems like the problem affects modules that use DROP_GIANT / PICKUP= _GIANT. >=20 > that's a good observation. I'll take a look a that later. Yes, that isn't really intended to be used publically. The pmc one is stale as system calls haven't run with Giant in several=20= releases. All the ones for g_topology_lock() also seem to be broken-by-designed. = There=20 is no good reason I can think of for g_topology_lock() to assert that G= iant=20 isn't held. I suspect phk@ just wanted to force geom to be locked with= out=20 Giant, but I'm not sure that is the best way to achieve that? Poul, is= that=20 correct? If you fix that you can remove almost all of the DROP_GIANT/PICKUP_GIAN= T in=20 the tree. They should really only be in the _sleep() and cv_wait_*()=20= functions where they are used to give Giant its "special" property of b= eing=20 dropped while asleep. --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1758681.vj4zSF7cnf>