On 14/9/23 14:47, Amir Goldstein wrote:
On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
Implement the mount querying syscalls agreed on at LSF/MM 2023. This is an
RFC with just x86_64 syscalls.
Excepting notification this should allow full replacement for
parsing /proc/self/mountinfo.
Since you mentioned notifications, I will add that the plan discussed
in LFSMM was, once we have an API to query mount stats and children,
implement fanotify events for:
mount [mntuid] was un/mounted at [parent mntuid],[dirfid+name]
As with other fanotify events, the self mntuid and dirfid+name
information can be omitted and without it, multiple un/mount events
from the same parent mntuid will be merged, allowing userspace
to listmnt() periodically only mntuid whose child mounts have changed,
with little risk of event queue overflow.
The possible monitoring scopes would be the entire mount namespace
of the monitoring program or watching a single mount for change in
its children mounts. The latter is similar to inotify directory children watch,
where the watches needs to be set recursively, with all the weight on
userspace to avoid races.
It's been my belief that the existing notification mechanisms don't
quite fully satisfy the needs of users of these calls (aka. the need
I found when implementing David's original calls into systemd).
Specifically the ability to process a batch of notifications at once.
Admittedly the notifications mechanism that David originally implemented
didn't fully implement what I found I needed but it did provide for a
settable queue length and getting a batch of notifications at a time.
Am I mistaken in my belief?
Don't misunderstand me, it would be great for the existing notification
mechanisms to support these system calls, I just have a specific use case
in mind that I think is important, at least to me.
Ian
