From: Al Viro <viro@ZenIV.linux.org.uk>
To: Beata Michalska <b.michalska@samsung.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, greg@kroah.com, jack@suse.cz,
tytso@mit.edu, adilger.kernel@dilger.ca, hughd@google.com,
lczerner@redhat.com, hch@infradead.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
kyungmin.park@samsung.com, kmpark@infradead.org
Subject: Re: [RFC v3 1/4] fs: Add generic file system event notifications
Date: Tue, 16 Jun 2015 17:21:47 +0100 [thread overview]
Message-ID: <20150616162147.GA17109@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1434460173-18427-2-git-send-email-b.michalska@samsung.com>
On Tue, Jun 16, 2015 at 03:09:30PM +0200, Beata Michalska wrote:
> Introduce configurable generic interface for file
> system-wide event notifications, to provide file
> systems with a common way of reporting any potential
> issues as they emerge.
>
> The notifications are to be issued through generic
> netlink interface by newly introduced multicast group.
>
> Threshold notifications have been included, allowing
> triggering an event whenever the amount of free space drops
> below a certain level - or levels to be more precise as two
> of them are being supported: the lower and the upper range.
> The notifications work both ways: once the threshold level
> has been reached, an event shall be generated whenever
> the number of available blocks goes up again re-activating
> the threshold.
>
> The interface has been exposed through a vfs. Once mounted,
> it serves as an entry point for the set-up where one can
> register for particular file system events.
Hmm...
1) what happens if two processes write to that file at the same time,
trying to create an entry for the same fs? WARN_ON() and fail for one
of them if they race?
2) what happens if fs is mounted more than once (e.g. in different
namespaces, or bound at different mountpoints, or just plain mounted
several times in different places) and we add an event for each?
More specifically, what should happen when one of those gets unmounted?
3) what's the meaning of ->active? Is that "fs_drop_trace_entry() hadn't
been called yet" flag? Unless I'm misreading it, we can very well get
explicit removal race with umount, resulting in cleanup_mnt() returning
from fs_event_mount_dropped() before the first process (i.e. write
asking to remove that entry) gets around to its deactivate_super(),
ending up with umount(2) on a filesystem that isn't mounted anywhere
else reporting success to userland before the actual fs shutdown, which
is not a nice thing to do...
4) test in fs_event_mount_dropped() looks very odd - by that point we
are absolutely guaranteed to have ->mnt_ns == NULL. What's that supposed
to do?
Al, trying to figure out the lifetime rules in all of that...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: Beata Michalska <b.michalska-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org,
jack-AlSwsSmVLrQ@public.gmane.org,
tytso-3s7WtUTddSA@public.gmane.org,
adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org,
hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
kmpark-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
Subject: Re: [RFC v3 1/4] fs: Add generic file system event notifications
Date: Tue, 16 Jun 2015 17:21:47 +0100 [thread overview]
Message-ID: <20150616162147.GA17109@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1434460173-18427-2-git-send-email-b.michalska-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Jun 16, 2015 at 03:09:30PM +0200, Beata Michalska wrote:
> Introduce configurable generic interface for file
> system-wide event notifications, to provide file
> systems with a common way of reporting any potential
> issues as they emerge.
>
> The notifications are to be issued through generic
> netlink interface by newly introduced multicast group.
>
> Threshold notifications have been included, allowing
> triggering an event whenever the amount of free space drops
> below a certain level - or levels to be more precise as two
> of them are being supported: the lower and the upper range.
> The notifications work both ways: once the threshold level
> has been reached, an event shall be generated whenever
> the number of available blocks goes up again re-activating
> the threshold.
>
> The interface has been exposed through a vfs. Once mounted,
> it serves as an entry point for the set-up where one can
> register for particular file system events.
Hmm...
1) what happens if two processes write to that file at the same time,
trying to create an entry for the same fs? WARN_ON() and fail for one
of them if they race?
2) what happens if fs is mounted more than once (e.g. in different
namespaces, or bound at different mountpoints, or just plain mounted
several times in different places) and we add an event for each?
More specifically, what should happen when one of those gets unmounted?
3) what's the meaning of ->active? Is that "fs_drop_trace_entry() hadn't
been called yet" flag? Unless I'm misreading it, we can very well get
explicit removal race with umount, resulting in cleanup_mnt() returning
from fs_event_mount_dropped() before the first process (i.e. write
asking to remove that entry) gets around to its deactivate_super(),
ending up with umount(2) on a filesystem that isn't mounted anywhere
else reporting success to userland before the actual fs shutdown, which
is not a nice thing to do...
4) test in fs_event_mount_dropped() looks very odd - by that point we
are absolutely guaranteed to have ->mnt_ns == NULL. What's that supposed
to do?
Al, trying to figure out the lifetime rules in all of that...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Beata Michalska <b.michalska@samsung.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, greg@kroah.com, jack@suse.cz,
tytso@mit.edu, adilger.kernel@dilger.ca, hughd@google.com,
lczerner@redhat.com, hch@infradead.org,
linux-ext4@vger.kernel.org, linux-mm@kvack.org,
kyungmin.park@samsung.com, kmpark@infradead.org
Subject: Re: [RFC v3 1/4] fs: Add generic file system event notifications
Date: Tue, 16 Jun 2015 17:21:47 +0100 [thread overview]
Message-ID: <20150616162147.GA17109@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1434460173-18427-2-git-send-email-b.michalska@samsung.com>
On Tue, Jun 16, 2015 at 03:09:30PM +0200, Beata Michalska wrote:
> Introduce configurable generic interface for file
> system-wide event notifications, to provide file
> systems with a common way of reporting any potential
> issues as they emerge.
>
> The notifications are to be issued through generic
> netlink interface by newly introduced multicast group.
>
> Threshold notifications have been included, allowing
> triggering an event whenever the amount of free space drops
> below a certain level - or levels to be more precise as two
> of them are being supported: the lower and the upper range.
> The notifications work both ways: once the threshold level
> has been reached, an event shall be generated whenever
> the number of available blocks goes up again re-activating
> the threshold.
>
> The interface has been exposed through a vfs. Once mounted,
> it serves as an entry point for the set-up where one can
> register for particular file system events.
Hmm...
1) what happens if two processes write to that file at the same time,
trying to create an entry for the same fs? WARN_ON() and fail for one
of them if they race?
2) what happens if fs is mounted more than once (e.g. in different
namespaces, or bound at different mountpoints, or just plain mounted
several times in different places) and we add an event for each?
More specifically, what should happen when one of those gets unmounted?
3) what's the meaning of ->active? Is that "fs_drop_trace_entry() hadn't
been called yet" flag? Unless I'm misreading it, we can very well get
explicit removal race with umount, resulting in cleanup_mnt() returning
from fs_event_mount_dropped() before the first process (i.e. write
asking to remove that entry) gets around to its deactivate_super(),
ending up with umount(2) on a filesystem that isn't mounted anywhere
else reporting success to userland before the actual fs shutdown, which
is not a nice thing to do...
4) test in fs_event_mount_dropped() looks very odd - by that point we
are absolutely guaranteed to have ->mnt_ns == NULL. What's that supposed
to do?
Al, trying to figure out the lifetime rules in all of that...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-06-16 16:21 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 13:09 [RFC v3 0/4] fs: Add generic file system event notifications Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-06-16 13:09 ` [RFC v3 1/4] " Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-06-16 16:21 ` Al Viro [this message]
2015-06-16 16:21 ` Al Viro
2015-06-16 16:21 ` Al Viro
2015-06-17 9:22 ` Beata Michalska
2015-06-17 9:22 ` Beata Michalska
2015-06-17 23:06 ` Dave Chinner
2015-06-17 23:06 ` Dave Chinner
2015-06-18 8:25 ` Beata Michalska
2015-06-18 8:25 ` Beata Michalska
2015-06-19 0:03 ` Dave Chinner
2015-06-19 0:03 ` Dave Chinner
2015-06-19 17:28 ` Beata Michalska
2015-06-19 17:28 ` Beata Michalska
2015-06-19 17:28 ` Beata Michalska
2015-06-19 23:21 ` Dave Chinner
2015-06-19 23:21 ` Dave Chinner
2015-06-22 15:46 ` Beata Michalska
2015-06-22 15:46 ` Beata Michalska
2015-06-18 11:17 ` Kinglong Mee
2015-06-18 11:17 ` Kinglong Mee
2015-06-18 14:50 ` Beata Michalska
2015-06-18 14:50 ` Beata Michalska
2015-06-24 8:47 ` Dmitry Monakhov
2015-06-24 8:47 ` Dmitry Monakhov
2015-06-24 15:31 ` Beata Michalska
2015-06-24 15:31 ` Beata Michalska
2015-06-24 16:26 ` Steve French
2015-06-24 16:26 ` Steve French
2015-06-26 7:30 ` Beata Michalska
2015-06-26 7:30 ` Beata Michalska
2015-07-22 15:55 ` Bartlomiej Zolnierkiewicz
2015-07-22 15:55 ` Bartlomiej Zolnierkiewicz
2015-07-30 8:22 ` Beata Michalska
2015-07-30 8:22 ` Beata Michalska
2015-06-16 13:09 ` [RFC v3 2/4] ext4: Add helper function to mark group as corrupted Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-07-22 10:40 ` Bartlomiej Zolnierkiewicz
2015-07-22 10:40 ` Bartlomiej Zolnierkiewicz
2015-06-16 13:09 ` [RFC v3 3/4] ext4: Add support for generic FS events Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-06-17 6:15 ` Leon Romanovsky
2015-06-17 6:15 ` Leon Romanovsky
2015-06-17 9:25 ` Beata Michalska
2015-06-17 9:25 ` Beata Michalska
2015-06-16 13:09 ` [RFC v3 4/4] shmem: " Beata Michalska
2015-06-16 13:09 ` Beata Michalska
2015-06-17 6:08 ` Leon Romanovsky
2015-06-17 6:08 ` Leon Romanovsky
2015-06-17 9:23 ` Beata Michalska
2015-06-17 9:23 ` Beata Michalska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150616162147.GA17109@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger.kernel@dilger.ca \
--cc=b.michalska@samsung.com \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kmpark@infradead.org \
--cc=kyungmin.park@samsung.com \
--cc=lczerner@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.