linux-kernel - Re: [RFC] annotating the remaining BKL users

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201009091315.54910.arnd@arndb.de>
Date:	Thu, 9 Sep 2010 13:15:54 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Kacur <jkacur@...hat.com>,
	Sam Ravnborg <sam@...nborg.org>, Jan Blunck <jblunck@...e.de>,
	linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [RFC] annotating the remaining BKL users

On Thursday 09 September 2010, Linus Torvalds wrote:
> On Wed, Sep 8, 2010 at 1:55 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >
> > I'd like to hear preferences for one approach or the other,
> > especially from Linus, so we can give this some better testing
> > in -next before the merge window.
> 
> Hmm. I like your patch. It seems to have a good balance of "select
> BKL" (for architectures that require it for some reason) and "depends
> on BKL" (for individual modules).

Actually, I was using "select" only for the cases where there is no
other option, like architectures that unconditionally reuire it.

> That said, I'd also like to see a comment _why_ the architectures in
> question depends on the BKL. Some of those look pretty historical (the
> sparc32 register window spill code? Does it _really_ need the BKL at
> all, or is that just a remnant of "let's get the BKL at each kernel
> entry").

Right. I'm pretty sure we can trivially fix all the arch code, I just
had no incentive to start that yet and instead did the annotations.
 
> So with the added rule that "each select BKL needs a quick comment
> why", I'd be happy with it. And maybe it would make people take a
> second look.

Ok. Making people take a look was also a reason why I posted this patch
separately. I might actually add comments to all of the "depends on BKL"
as well to make it clear which category they all fall into and motivate
janitors to take care of the easy ones.

As mentioned in another thread, the only nontrivial ones besides
fs/{locks.c,lockd} (which we need to fix before the BKL can become
optional) are probably:

drivers/{media,staging,usb/gadget,char/raw}
fs/{autofs,coda,hpfs,isofs,ncpfs,nfs,smbfs,udf,ufs}
net/{appletalk,ipx,irda,ax25}

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/