Killing Giant for 13
Gary Jennejohn
gljennjohn at gmail.com
Wed Nov 27 07:26:20 UTC 2019
On Tue, 26 Nov 2019 15:23:17 -0700
Warner Losh <imp at bsdimp.com> wrote:
> On Tue, Nov 26, 2019 at 11:47 AM Gary Jennejohn <gljennjohn at gmail.com>
> wrote:
>
> > On Tue, 26 Nov 2019 19:35:55 +0100
> > Michael Gmelin <freebsd at grem.de> wrote:
> >
> > > On Tue, 26 Nov 2019 11:21:20 -0700
> > > Warner Losh <imp at bsdimp.com> wrote:
> > >
> > >
> > > > However, the hpt27xx driver turns out not to be Giant locked on
> > > > versions of FreeBSD >= 10. So it's off the list.
> > >
> > > Is that a real list that could be made publicly available, so users can
> > > check if any of the hardware they use will be affected?
> > >
> >
> > cd /usr/src/sys
> > grep -Rl D_NEEDGIANT (assuming the user has the right permissions)
> >
> > Drivers which use GIANT have this somewhere in their code.
> >
> > I found 30 C file hits in HEAD.
> >
>
> Yea, about 25 drivers, 5 of which look to be trivial to change over, some
> already have. It used to be the case that all dev_t's in the tree were
> marked NEEDGIANT because they did things like check permissions or other
> such things that required Giant and this was easier than narrowing it down
> to just the little bit of code that needed it...
>
> And then there's all the interrupt handlers that aren't marked MPSAFE...
> how to grep for that? I think I may invent a NEEDS_GIANT sort of thing in
> preference to MPSAFE.
>
> And then there's sysctl proc handlers not marked safe. Same notion as the
> interrupt handlers.
>
> And finally all the direct use of the Giant lock, most of which I'll
> replace by a bus_lock()/bus_unlock() API, or are for the kbd / console mess
> (which I'll likely replace with another wrapper), and then the odd driver
> that needs Giant for some reason (I think there's 2 or 3 of these).
>
I could maybe use something like bus_lock()/bus_unlock() in the
rtsx driver because the OpenBSD code stil uses splxxx()s and I'm
not sure how to replace them.
> That's the audit I wanted to get done before posting next steps.
>
--
Gary Jennejohn
More information about the freebsd-arch
mailing list