rename of VM_NR_PDFLUSH_THREADS breaks strace compilation

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.

This:

include/uapi/linux/sysctl.h +1 -1

[...]
-       VM_NR_PDFLUSH_THREADS=15, /* nr_pdflush_threads */
+       VM_UNUSED15=15,         /* was: int: nr_pdflush_threads */

causes this when trying to build strace:

+ ./bootstrap
configure.ac:54: installing './compile'
configure.ac:47: installing './config.guess'
configure.ac:47: installing './config.sub'
configure.ac:45: installing './install-sh'
configure.ac:45: installing './missing'
Makefile.am: installing './depcomp'
Makefile.am:975: warning: variable 'ioctlsort_LDFLAGS' is defined but no program or Makefile.am:975: library has 'ioctlsort' as canonical name (possible typo)
parallel-tests: installing './test-driver'
+ ./configure
++ nproc
+ make -j 10
In file included from defs.h:308,
from sysctl.c:31:
xlat/sysctl_vm.h:23:7: error: ‘VM_NR_PDFLUSH_THREADS’ undeclared here (not in a function) XLAT(VM_NR_PDFLUSH_THREADS),
^~~~~~~~~~~~~~~~~~~~~
xlat.h:49:35: note: in definition of macro ‘XLAT’

# define XLAT(val)   { (unsigned)(val), #val }
^~~

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

xlat/sysctl_vm.in +0 -0

index 3c2b4739..30784c2a 100644

Quoted 14 lines · Rafael Aquini

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

xlat/sysctl_vm.in VM_DIRTY_BACKGROUND · line 10

Quoted 12 lines

xlat/sysctl_vm.in +0 -1

index 3c2b4739..30784c2a 100644
@@ -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.

Quoted 15 lines · Heiko Carstens

Quoted 14 lines · Rafael Aquini

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

Quoted 17 lines

xlat/sysctl_vm.in VM_DIRTY_BACKGROUND · line 10

Quoted 12 lines

xlat/sysctl_vm.in +0 -1

index 3c2b4739..30784c2a 100644
@@ -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.

Quoted 34 lines · Rafael Aquini

Quoted 15 lines · Heiko Carstens

Quoted 14 lines · Rafael Aquini

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

Quoted 17 lines

xlat/sysctl_vm.in VM_DIRTY_BACKGROUND · line 10

Quoted 12 lines

xlat/sysctl_vm.in +0 -1

index 3c2b4739..30784c2a 100644
@@ -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.

Quoted 4 lines

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.

Quoted 40 lines · Greg Kroah-Hartman

Quoted 34 lines · Rafael Aquini

Quoted 15 lines · Heiko Carstens

Quoted 14 lines · Rafael Aquini

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

Quoted 17 lines

xlat/sysctl_vm.in VM_DIRTY_BACKGROUND · line 10

Quoted 12 lines

xlat/sysctl_vm.in +0 -1

index 3c2b4739..30784c2a 100644
@@ -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.

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 58 lines · Rafael Aquini

Quoted 40 lines · Greg Kroah-Hartman

Quoted 34 lines · Rafael Aquini

Quoted 15 lines · Heiko Carstens

Quoted 14 lines · Rafael Aquini

Review

Quoted 7 lines · Heiko Carstens

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.

(quoted diff) +1 -1

-       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?

Quoted 17 lines

xlat/sysctl_vm.in VM_DIRTY_BACKGROUND · line 10

Quoted 12 lines

xlat/sysctl_vm.in +0 -1

index 3c2b4739..30784c2a 100644
@@ -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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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 <[email protected]>
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-tSWWG44O7X1aa/[email protected]>
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.