Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Nov 2022 10:58:04 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        sgk@troutmask.apl.washington.edu
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Giant Locked drivers
Message-ID:  <CANCZdfo3VKyrQXx3-%2B52-XX53SbuMnDsXQhgb8GT=ZESaeyJ_w@mail.gmail.com>
In-Reply-To: <Y3PR2GXR42LcdbDd@troutmask.apl.washington.edu>
References:  <CANCZdfrfNzb1O91T4ivMXPsUGu7mYX80pJxvQu07oe2AF=YXCw@mail.gmail.com> <Y3PR2GXR42LcdbDd@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000b442b905ed86198b
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 15, 2022 at 10:52 AM Steve Kargl <
sgk@troutmask.apl.washington.edu> wrote:

> On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote:
> >
> > It's no secret fiant-locked drivers' days are numbered. We've been more
> > sluggish about eliminating Giant than had been hoped. I plan in the
> coming
> > weeks to add a tunable 'debug.giant_drivers' which initially will be set
> to
> > enable/disable giant-locked drivers in the tree.
> >
> > When set to 0, you get today's behavior. If set to 1, it will no longer
> > allow drivers that don't request MPSAFE interrupt handlers from
> registering
> > (the interrupt setup will return an error).
> >
> > This will allow us to understand what is lost if we throw the switch, and
> > allow users to proactively test their systems to see if they are
> > affected or not (and if they are, if they want to live without the
> > functionality, or want to fund work in the area).
> >
> > Comments?
> >
>
> Is there a list of effected drivers?  Grepping /var/run/dmesg.boot
> on my system shows only "atkbd0: [GIANT-LOCKED]".  A scan of atkbd(4)
> shows
>
>    This driver is required for the console driver syscons(4) or vt(4).
>
> So, setting debug.giant_drivers=1 will brick all FreeBSD workstations?
>

You could still access them via serial port or the network.

And I think USB-based systems would be fine. The comment you quoted is
slightly overstated.

And yes, the point is to show the pain and get people to get off their !$#^
and do something if they care.

Warner

--000000000000b442b905ed86198b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 15, 2022 at 10:52 AM Stev=
e Kargl &lt;<a href=3D"mailto:sgk@troutmask.apl.washington.edu">sgk@troutma=
sk.apl.washington.edu</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh =
wrote:<br>
&gt; <br>
&gt; It&#39;s no secret fiant-locked drivers&#39; days are numbered. We&#39=
;ve been more<br>
&gt; sluggish about eliminating Giant than had been hoped. I plan in the co=
ming<br>
&gt; weeks to add a tunable &#39;debug.giant_drivers&#39; which initially w=
ill be set to<br>
&gt; enable/disable giant-locked drivers in the tree.<br>
&gt; <br>
&gt; When set to 0, you get today&#39;s behavior. If set to 1, it will no l=
onger<br>
&gt; allow drivers that don&#39;t request MPSAFE interrupt handlers from re=
gistering<br>
&gt; (the interrupt setup will return an error).<br>
&gt; <br>
&gt; This will allow us to understand what is lost if we throw the switch, =
and<br>
&gt; allow users to proactively test their systems to see if they are<br>
&gt; affected or not (and if they are, if they want to live without the<br>
&gt; functionality, or want to fund work in the area).<br>
&gt; <br>
&gt; Comments?<br>
&gt; <br>
<br>
Is there a list of effected drivers?=C2=A0 Grepping /var/run/dmesg.boot<br>
on my system shows only &quot;atkbd0: [GIANT-LOCKED]&quot;.=C2=A0 A scan of=
 atkbd(4)<br>
shows<br>
<br>
=C2=A0 =C2=A0This driver is required for the console driver syscons(4) or v=
t(4).<br>
<br>
So, setting debug.giant_drivers=3D1 will brick all FreeBSD workstations?<br=
></blockquote><div><br></div><div>You could still access them via serial po=
rt or the network.</div><div><br></div><div>And I think USB-based systems w=
ould be fine. The comment you quoted is slightly overstated.</div><div><br>=
</div><div>And yes, the point is to show the pain and get people to get off=
 their !$#^ and do something if they care.</div><div><br></div><div>Warner<=
/div></div></div>

--000000000000b442b905ed86198b--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo3VKyrQXx3-%2B52-XX53SbuMnDsXQhgb8GT=ZESaeyJ_w>