linux-kernel - Re: [PATCH 01/10] mm: make cleancache.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]

Date:	Tue, 22 Sep 2015 11:20:38 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular

On Mon, Aug 24, 2015 at 09:10:40PM -0400, Paul Gortmaker wrote:
> [Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular] On 24/08/2015 (Mon 20:10) Konrad Rzeszutek Wilk wrote:
> 
> > On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> > >The Kconfig currently controlling compilation of this code is:
> > >
> > >config CLEANCACHE
> > >bool "Enable cleancache driver to cache clean pages if tmem is present"
> > >
> > >...meaning that it currently is not being built as a module by anyone.
> > 
> > Why not make it a tristate?
> 
> Simple.  I'm making the code consistent with its current behaviour.
> I'm not looking to extend functionality in code that I don't know
> intimately.  I can't do that and do it reliably and guarantee it
> works as a module when it has never been used as such before.
> 
> I've got about 130 of these and counting.  Some of them have been bool
> since before git history ; before the turn of the century.  If there was
> demand for them to be tristate, then it would have happened by now.  So
> clearly there is no point in looking at making _those_ tristate.
> 
> I did have one uart driver author indicate that he _meant_ his code to
> be tristate, and he tested it as such, and asked if I would convert it
> to tristate on his behalf.  And that was fine and I did exactly that.
> 
> But unless there are interested users who want their code tristate and
> can vouch that their code works OK as such, I can only make the code
> consistent with the implicit non-modular behaviour that the Kconfig and
> Makefiles have dictated up to now.  Are there such users for CLEANCACHE?

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>

Sorry for taking so long. It really cannot be tri-state (I tried
making it an module) as the cleancache hooks are tied in the mm/filemap.c.

> 
> Paul.
> --
> 
> > 
> > 
> > >
> > >Lets remove the couple traces of modularity so that when reading the
> > >driver there is no doubt it is builtin-only.
> > >
> > >Since module_init translates to device_initcall in the non-modular
> > >case, the init ordering remains unchanged with this commit.
> > >
> > >Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > >Cc: linux-mm@...ck.org
> > >Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
> > >---
> > > mm/cleancache.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > >diff --git a/mm/cleancache.c b/mm/cleancache.c
> > >index 8fc50811119b..ee0646d1c2fa 100644
> > >--- a/mm/cleancache.c
> > >+++ b/mm/cleancache.c
> > >@@ -11,7 +11,7 @@
> > >  * This work is licensed under the terms of the GNU GPL, version 2.
> > >  */
> > > 
> > >-#include <linux/module.h>
> > >+#include <linux/init.h>
> > > #include <linux/fs.h>
> > > #include <linux/exportfs.h>
> > > #include <linux/mm.h>
> > >@@ -316,4 +316,4 @@ static int __init init_cleancache(void)
> > > #endif
> > > 	return 0;
> > > }
> > >-module_init(init_cleancache)
> > >+device_initcall(init_cleancache)
> > 
> > 
--
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/