Skip site navigation (1)Skip section navigation (2)
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>