[-next] rename of VM_NR_PDFLUSH_THREADS breaks strace compilation

[Rafael Aquini]

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

Cheers,

-- Rafael