linux-kernel - Re: [PATCH] fs/drop_caches: move drop

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]

Date:   Tue, 21 Mar 2023 11:10:25 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Yangtao Li <frank.li@...o.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH] fs/drop_caches: move drop_caches sysctls into its own
 file

On Tue, Mar 21, 2023 at 05:19:18PM +0000, Matthew Wilcox wrote:
> On Tue, Mar 21, 2023 at 09:56:03AM -0700, Luis Chamberlain wrote:
> > On Tue, Mar 21, 2023 at 04:42:32PM +0000, Matthew Wilcox wrote:
> > > On Tue, Mar 21, 2023 at 09:09:07PM +0800, Yangtao Li wrote:
> > > > +static struct ctl_table drop_caches_table[] = {
> > > > +	{
> > > > +		.procname	= "drop_caches",
> > > > +		.data		= &sysctl_drop_caches,
> > > > +		.maxlen		= sizeof(int),
> > > > +		.mode		= 0200,
> > > > +		.proc_handler	= drop_caches_sysctl_handler,
> > > > +		.extra1		= SYSCTL_ONE,
> > > > +		.extra2		= SYSCTL_FOUR,
> > > > +	},
> > > > +	{}
> > > > +};
> > > 
> > > Could we avoid doing this until we no longer need an entire zero entry
> > > after the last one? 
> > 
> > That may be 2-3 kernel release from now. The way to use ARRAY_SIZE()
> > really is to deprecate the crap APIs that allow messy directory sysctl
> > structures.
> 
> I'm OK with waiting another year to commence this cleanup.  We've lived
> with the giant tables for decades already.  Better to get the new API
> right than split the tables now, then have to touch all the places
> again.

We can do that sure.

  Luis