linux-kernel - Re: [PATCH 05/10] fs: make locks.c explicitly non-modular

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151214153359.GI32362@windriver.com>
Date:	Mon, 14 Dec 2015 10:34:00 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Jeff Layton <jlayton@...chiereds.net>
CC:	Alexander Viro <viro@...iv.linux.org.uk>,
	<linux-kernel@...r.kernel.org>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 05/10] fs: make locks.c explicitly non-modular

[Re: [PATCH 05/10] fs: make locks.c explicitly non-modular] On 14/12/2015 (Mon 06:31) Jeff Layton wrote:

> On Sat, 12 Dec 2015 16:30:07 -0500
> Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> 
> > The Kconfig currently controlling compilation of this code is:
> > 
> > config FILE_LOCKING
> >      bool "Enable POSIX file locking API" if EXPERT
> > 
> > ...meaning that it currently is not being built as a module by anyone.
> > 
> > Lets remove the couple traces of modularity so that when reading the
> > driver there is no doubt it is builtin-only.
> > 

[...]

> 
> Looks fine to me and I doubt we'll see any merge conflicts with
> anything I have queued so far. Do you need any of us to pick any of
> these up or are you going to be merging them as a set?

I was hoping to spread as many of these around as possible so I don't
end up with a giant pull request to Linus.  There is code out there
without a clear maintainership path, so eventually I'll have to send
some his way (or via akpm) but the less that end up in that pile, the
better IMHO.

It looks like the hugetlb init level change upset one of the automated
qemu 0-day boot tests, so I need to investigate that next.

Paul.
--

> 
> Acked-by: Jeff Layton <jlayton@...chiereds.net>
--
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/