[-next] rename of VM_NR_PDFLUSH_THREADS breaks strace compilation

[Rafael Aquini]

On Fri, Dec 07, 2018 at 07:17:17AM -0500, Rafael Aquini wrote:
> On Fri, Dec 07, 2018 at 12:54:12PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Dec 07, 2018 at 06:16:01AM -0500, Rafael Aquini wrote:
> > > On Fri, Dec 07, 2018 at 12:01:46PM +0100, Heiko Carstens wrote:
> > > > On Fri, Dec 07, 2018 at 05:53:13AM -0500, Rafael Aquini wrote:
> > > > > On Fri, Dec 07, 2018 at 08:58:07AM +0100, Heiko Carstens wrote:
> > > > > > Hi Rafael,
> > > > > > 
> > > > > > your patch 77cab92a2cb1 ("sysctl: clean up nr_pdflush_threads
> > > > > > leftover") in linux-next breaks strace compilation if used with kernel
> > > > > > headers from linux-next.
> > > > > > -       VM_NR_PDFLUSH_THREADS=15, /* nr_pdflush_threads */
> > > > > > +       VM_UNUSED15=15,         /* was: int: nr_pdflush_threads */
> > > > > The nr_pdflush_threads (VM_NR_PDFLUSH_THREADS) tunable has been obsolete since 2.6.32
> > > > > and it was, excepting by the bit in the referred patch, completely removed on 4.15.
> > > > > 
> > > > > I think you just need to patch strace source with the following hunk, in
> > > > > order to reflect the removal. Would you mind checking it?
> > > > > 
> > > > > diff --git a/xlat/sysctl_vm.in b/xlat/sysctl_vm.in
> > > > > index 3c2b4739..30784c2a 100644
> > > > > --- a/xlat/sysctl_vm.in
> > > > > +++ b/xlat/sysctl_vm.in
> > > > > @@ -5,7 +5,6 @@ VM_DIRTY_BACKGROUND
> > > > >  VM_DIRTY_RATIO
> > > > >  VM_DIRTY_WB_CS
> > > > >  VM_DIRTY_EXPIRE_CS
> > > > > -VM_NR_PDFLUSH_THREADS
> > > > >  VM_OVERCOMMIT_RATIO
> > > > >  VM_PAGEBUF
> > > > >  VM_HUGETLB_PAGES
> > > > 
> > > > I'll leave that up to Dmitry to decide what to do here. At least it
> > > > won't be possible to compile old strace versions with new kernel
> > > > headers if the kernel change gets merged upstream.
> > > >
> > > 
> > > It escapes me why strace bootstrap needs to tabulate these sysctl_vm, as no one 
> > > of these defs are referenced in the rest of the code, let alone 
> > > /proc/sys/vm/nr_pdflush_threads that means nothing since per-BDI flusher threads
> > > were introduced almost 10 years ago.
> > 
> > This isn't ok, we shouldn't break userspace, I'll go revert this patch.
> >
> > Rafael, feel free to resend but just add a comment that says it is
> > obsolete or something.
> > 
> 
> This is more like autotools insanity on the app buildscripts part than proper
> userspace breakage. Linux sysctl man page brings a nice note on why one
> should not rely on the syscall:
> 
> NOTES
>        Glibc does not provide a wrapper for this system call; call it using syscall(2).
>        Or rather...  don't call it: use of this system call has long been
>        discouraged, and it is so unloved that it is likely to disappear in a 
>        future kernel version.  Since Linux 2.6.24, uses of this system call result in
>        warnings in the kernel log.  Remove it from your programs now; use the /proc/sys interface instead.
> 
>        This system call is available only if the kernel was configured with the CONFIG_SYSCTL_SYSCALL option.
> 
> 
> also worth to note that CONFIG_SYSCTL_SYSCALL defaults to N
>

Here's a little bit of history to add to the rationale on why the
revert, in this case, does not seem to be the correct path:

Initially, upstream commit:

commit 3965c9ae47d64aadf6f13b6fcd37767b83c0689a
Author: Wanpeng Li <liwp at linux.vnet.ibm.com>
Date:   Tue Jul 31 16:41:52 2012 -0700

    mm: prepare for removal of obsolete /proc/sys/vm/nr_pdflush_threads


effectively removed nr_pdflush_threads storage space, ceased exporting
VM_NR_PDFLUSH_THREADS to struct bin_table bin_vm_table[] and replaced
the procname handler with a deprecation note to dmesg.



then, the following upstream commit completely removed the entry from procfs:

commit b35bd0d9f8a8ea17aae40893e18274d191a2d2c5
Author: Jens Axboe <axboe at kernel.dk>
Date:   Sat Sep 30 23:39:05 2017 -0600

    sysctl: remove /proc/sys/vm/nr_pdflush_threads


Only bit missing is the cleanup proposed with this patch. If we cannot
clean up something rigthfully deprecated and removed from so long, then
we're certainly dead in the water.

This will be my last email on the matter, I promise!

Cheers,
-- Rafael