[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yfwyu0N4+f51J9OU@bombadil.infradead.org>
Date: Thu, 3 Feb 2022 11:53:31 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
tangmeng <tangmeng@...ontech.com>, keescook@...omium.org,
yzaikin@...gle.com, john.stultz@...aro.org, sboyd@...nel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v5] kernel/time: move timer sysctls to its own file
On Thu, Feb 03, 2022 at 10:35:06AM +0100, Thomas Gleixner wrote:
> On Wed, Feb 02 2022 at 17:17, Luis Chamberlain wrote:
> > On Thu, Feb 03, 2022 at 01:21:46AM +0100, Thomas Gleixner wrote:
> > *Today* all filesystem syctls now get reviewed by fs folks. They are
> > all tidied up there.
> >
> > In the future x86 folks can review their sysctls. But for no reason
> > should I have to review every single knob. That's not scalable.
>
> Fair enough, but can we please have a changelog which explains the
> rationale to the people who have not been part of that discussion and
> decision.
Sure thing, tangmeng please update the commit log a bit better.
> >> That aside, I'm tired of this because this is now at V5 and you still
> >> failed to fix the fallout reported by the 0-day infrastructure vs. this
> >> part of the patch:
> >>
> >> > +static int __init timer_sysctl_init(void)
> >> > +{
> >> > + register_sysctl_init("kernel", timer_sysctl);
> >> > + return 0;
> >> > +}
> >>
> >> kernel/time/timer.c: In function 'timer_sysctl_init':
> >> >> kernel/time/timer.c:284:9: error: implicit declaration of function 'register_sysctl_init'; did you mean 'timer_sysctl_init'? [-Werror=implicit-function-declaration]
> >> 284 | register_sysctl_init("kernel", timer_sysctl);
> >> | ^~~~~~~~~~~~~~~~~~~~
> >>
> >
> > That's an issue with the patch being tested on a tree where that
> > routine is not present?
>
> From the report:
>
> ...
> [also build test ERROR on linus/master
>
> Linus tree has this interface. So that's not the problem.
>
> Hint #1: The interfaxce is not available unconditionally
>
> Hint #2: The 0-day reports provide the config file which exposes the
> fail
tangmeng, please fix.
Luis
Powered by blists - more mailing lists