Date:   Tue, 21 Mar 2023 11:10:25 -0700
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Yangtao Li <frank.li@vivo.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Christian Brauner <brauner@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>,
        Iurii Zaikin <yzaikin@google.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
Subject: Re: [PATCH] fs/drop_caches: move drop_caches sysctls into its own
 file
Message-ID: <ZBnzEY2PLbUtMKqX@bombadil.infradead.org>
References: <20230321130908.6972-1-frank.li@vivo.com>
 <ZBneeOYHKBZl8SGe@casper.infradead.org>
 <ZBnho5yPbXIQs752@bombadil.infradead.org>
 <ZBnnFtKVgAFQ4yeo@casper.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZBnnFtKVgAFQ4yeo@casper.infradead.org>
Sender: Luis Chamberlain <mcgrof@infradead.org>
Precedence: bulk

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