Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8

["Paul Gortmaker" <paul.gortmaker@windriver.com>]

[Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8] On 15/01/2021 (Fri 09:57) Luca Boccassi wrote:

> On Fri, 2021-01-15 at 08:37 +0000, Richard Purdie wrote:
> > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote:
> > > Recent systemd started using ascii args to "hidepid=" mount options
> > > for proc fs - unconditionally -- even though kernels older than v5.8
> > > emit an error message on each attempt:
> > > 
> > > root@qemux86-64:~# cat /proc/version
> > > Linux version 5.4.87-yocto-standard (oe-user@oe-host) (gcc version 10.2.0 (GCC)) #1 SMP PREEMPT Fri Jan 8 01:47:13 UTC 2021
> > > root@qemux86-64:~# dmesg|grep proc:
> > > [   29.487995] proc: Bad value for 'hidepid'
> > > [   43.170571] proc: Bad value for 'hidepid'
> > > [   44.175615] proc: Bad value for 'hidepid'
> > > [   46.213300] proc: Bad value for 'hidepid'
> > > root@qemux86-64:~#
> 
> Wouldn't it be better to patch the kernel to downgrade that message to
> debug level?

The problem is that the breakage is forced upon older kernels, so you'd
have to effectively mainline that kind of "fix" to v5.12 (where there is
no problem) and then you could in theory request it for v5.4 linux-stable
according to "stable rules".

Besides, if something with root/mount priv. is consistently trying to
drive a square peg into a round hole - by trying to mount something and
failing -- it should be something that a sysadmin would want to
investigate.  Which is precisely why I am here now.  I think burying it
at debug level is counterproductive to that.


> > > +The systemd maintainer has dismissed this as something people should
> > > +simply ignore[1] and has no interest in trying to avoid it by
> > > +proactively checking the kernel version, so people can safely assume
> > > +that they will never see this version check commit upstream.
> > > +
> > > +However, as can be seen above, telling people to just ignore it is not
> > > +an option, as we'll end up answering the same question and dealing with
> > > +the same bug over and over again.
> > > +
> > > +The commit that triggers this is systemd v247-rc1~378^2~3 -- so any
> > > +systemd 247 and above plus kernel v5.7 or older will need this.
> > > +
> > > +[1] https://github.com/systemd/systemd/issues/16896
> > > +
> > > +Upstream-Status: Actively hostile
> > 
> > The status needs to be
> > 
> > Upstream-Status: Denied [Actively hostile 
> > https://github.com/systemd/systemd/issues/16896]
> > 
> > (so our tools have an idea of what status patches are in)
> 
> Paul, please, let's avoid loaded language - Denied is fine by itself
> and conveys what it needs to. I understand it can be frustrating when
> upstream maintainers do not agree with user assessments, but the linked
> discussion was polite and professional and there's no need to call it
> "hostile".

Normally I'd agree with you, but it isn't just this one thread/instance,
but instead *years* of continued "my way or the highway" behaviour
demonstrated by systemd on various lists like LKML, for all to see.  In
any case, in the interest of not breaking existing tooling, and getting
the fix to our users, I am fine with it being changed to simply be:

Upstream-Status: Denied [https://github.com/systemd/systemd/issues/16896]

Paul.
--

> 
> Also, speaking as an upstream maintainer, I'd be willing to review a
> patch that adds a log_debug notice to advise to ignore the error if the
> fallback path is taken. It's low cost and reasonable, so I don't think
> it would be a problem to merge it.
> 
> > https://wiki.yoctoproject.org/wiki/Best_Known_Methods#Patch_Comments
> 
> Richard, FYI this appears to be an empty page.
> 
> -- 
> Kind regards,
> Luca Boccassi