On Wed, 2019-04-03 at 12:17 -0600, Neil Tallim wrote: > I was able to confirm that the problem doesn't occur with Debian's > 4.19 series on unrelated hardware, however, and it looks like the > problem has been resolved for a while in stock kernels.
OK, thanks for confirming this. > https://lists.ubuntu.com/archives/kernel-team/2018-May/092723.html > I wasn't able to find an equivalent in Debian's patchsets, which led > me to check upstream; more on that below. Thanks for the reference. I had a look at the Linux mainline master and it appears that it was never affected by this issue, because the SSB line was added *after* the Seccomp one lost its trailing \n character. > After digging around for a while, it looks like this may be a side- > effect of how LTSI works, though I'll report it anyway, in hopes that > it can be addressed without violating the "don't break the userspace > ABI" policy. Any semi-recent kernel version should be unaffected. That sounds like a good idea to me, thanks. > The following patch adds a "NoNewPrivs" line to /proc/<pid>/status, > where the blank appears in 4.4. It doesn't look like it was ever > backported into the tree, or, rather, it seems to be the case that > retpoline logic, which assumed there was text right after the > capabilities block, was backported directly, leading to the gap. Ack. This code seems like a very fragile design and not a very good API but at least the current convention of printing the \n before each new option should prevent future additions of blank lines. > In any case, this is definitely an issue that should be fixed in > (specific versions of) the kernel. I still think iotop should be > synced to gain tolerance to unexpected input, but it isn't a Debian- > specific problem in light of what's been discussed here. That will happen eventually, but it won't reach Debian buster because we are in the freeze now and the bug is not important enough. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
