[Fixed address of linux-fsdevel]
On Wed, Nov 6, 2024 at 12:00 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Wed, Nov 6, 2024 at 10:59 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
> > On Wed, Nov 06, 2024 at 02:09:58PM +1100, Aleksa Sarai wrote:
> > > overlayfs helpfully provides a lot of of information when setting up a
> > > mount, but unfortunately when using the fsopen(2) API, a lot of this
> > > information is mixed in with the general kernel log.
> > >
> > > In addition, some of the logs can become a source of spam if programs
> > > are creating many internal overlayfs mounts (in runc we use an internal
> > > overlayfs mount to protect the runc binary against container breakout
> > > attacks like CVE-2019-5736, and xino_auto=on caused a lot of spam in
> > > dmesg because we didn't explicitly disable xino[1]).
> > >
> > > By logging to the fs_context, userspace can get more accurate
> > > information when using fsopen(2) and there is less dmesg spam for
> > > systems where a lot of programs are using fsopen("overlay"). Legacy
> > > mount(2) users will still see the same errors in dmesg as they did
> > > before (though the prefix of the log messages will now be "overlay"
> > > rather than "overlayfs").
>
> I am not sure about the level of risk in this format change.
> Miklos, WDYT?
>
> > >
> > > [1]: https://bbs.archlinux.org/viewtopic.php?pid=2206551
> > >
> > > Signed-off-by: Aleksa Sarai <cyphar@xxxxxxxxxx>
> > > ---
> >
> > To me this sounds inherently useful! So I'm all for it.
> >
>
> [CC: Karel]
>
> I am quite concerned about this.
> I have a memory that Christian suggested to make this change back in the
> original conversion to new mount API, but back then mount tool
> did not print out the errors to users properly and even if it does
> print out errors,
> some script could very well be ignoring them.
>
> My strong feeling is that suppressing legacy errors to kmsg should be opt-in
> via the new mount API and that it should not be the default for libmount.
> IMO, it is certainly NOT enough that new mount API is used by userspace
> as an indication for the kernel to suppress errors to kmsg.
> I have no problem with reporting errors to both userspace and kmsg
> without opt-in from usersapce.
>
> Furthermore, looking at the existing invalfc() calls in overlayfs, I see that
> a few legacy pr_err() were converted to invalfc() with this commit
> (signed off by myself):
> 819829f0319a ovl: refactor layer parsing helpers
>
> I am not really sure if the discussion about suppressing the kmsg errors was
> resolved or dismissed or maybe it only happened in my head??
>
> Thanks,
> Amir.
