From: David Howells <dhowells@redhat.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: dhowells@redhat.com, viro@zeniv.linux.org.uk, raven@themaw.net, kzak@redhat.com, jlayton@redhat.com, mszeredi@redhat.com, nicolas.dichtel@6wind.com, christian@brauner.io, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [GIT PULL] Mount notifications Date: Mon, 03 Aug 2020 16:27:49 +0100 [thread overview] Message-ID: <1842689.1596468469@warthog.procyon.org.uk> (raw) Hi Linus, Here's a set of patches to add notifications for mount topology events, such as mounting, unmounting, mount expiry, mount reconfiguration. The first patch in the series adds a hard limit on the number of watches that any particular user can add. The RLIMIT_NOFILE value for the process adding a watch is used as the limit. Even if you don't take the rest of the series, can you at least take this one? An LSM hook is included for an LSM to rule on whether or not a mount watch may be set on a particular path. This series is intended to be taken in conjunction with the fsinfo series which I'll post a pull request for shortly and which is dependent on it. Karel Zak[*] has created preliminary patches that add support to libmount and Ian Kent has started working on making systemd use them. [*] https://github.com/karelzak/util-linux/commits/topic/fsinfo Note that there have been some last minute changes to the patchset: you wanted something adding and Miklós wanted some bits taking out/changing. I've placed a tag, fsinfo-core-20200724 on the aggregate of these two patchsets that can be compared to fsinfo-core-20200803. To summarise the changes: I added the limiter that you wanted; removed an unused symbol; made the mount ID fields in the notificaion 64-bit (the fsinfo patchset has a change to convey the mount uniquifier instead of the mount ID); removed the event counters from the mount notification and moved the event counters into the fsinfo patchset. ==== WHY? ==== Why do we want mount notifications? Whilst /proc/mounts can be polled, it only tells you that something changed in your namespace. To find out, you have to trawl /proc/mounts or similar to work out what changed in the mount object attributes and mount topology. I'm told that the proc file holding the namespace_sem is a point of contention, especially as the process of generating the text descriptions of the mounts/superblocks can be quite involved. The notification generated here directly indicates the mounts involved in any particular event and gives an idea of what the change was. This is combined with a new fsinfo() system call that allows, amongst other things, the ability to retrieve in one go an { id, change_counter } tuple from all the children of a specified mount, allowing buffer overruns to be dealt with quickly. This is of use to systemd to improve efficiency: https://lore.kernel.org/linux-fsdevel/20200227151421.3u74ijhqt6ekbiss@ws.net.home/ And it's not just Red Hat that's potentially interested in this: https://lore.kernel.org/linux-fsdevel/293c9bd3-f530-d75e-c353-ddeabac27cf6@6wind.com/ David --- The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7: Linux 5.8-rc6 (2020-07-19 15:41:18 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/mount-notifications-20200803 for you to fetch changes up to 841a0dfa511364fa9a8d67512e0643669f1f03e3: watch_queue: sample: Display mount tree change notifications (2020-08-03 12:15:38 +0100) ---------------------------------------------------------------- Mount notifications ---------------------------------------------------------------- David Howells (5): watch_queue: Limit the number of watches a user can hold watch_queue: Make watch_sizeof() check record size watch_queue: Add security hooks to rule on setting mount watches watch_queue: Implement mount topology and attribute change notifications watch_queue: sample: Display mount tree change notifications Documentation/watch_queue.rst | 12 +- arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm/tools/syscall.tbl | 1 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/ia64/kernel/syscalls/syscall.tbl | 1 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + fs/Kconfig | 9 ++ fs/Makefile | 1 + fs/mount.h | 18 +++ fs/mount_notify.c | 222 ++++++++++++++++++++++++++++ fs/namespace.c | 22 +++ include/linux/dcache.h | 1 + include/linux/lsm_hook_defs.h | 3 + include/linux/lsm_hooks.h | 6 + include/linux/sched/user.h | 3 + include/linux/security.h | 8 + include/linux/syscalls.h | 2 + include/linux/watch_queue.h | 7 +- include/uapi/asm-generic/unistd.h | 4 +- include/uapi/linux/watch_queue.h | 31 +++- kernel/sys_ni.c | 3 + kernel/watch_queue.c | 8 + samples/watch_queue/watch_test.c | 41 ++++- security/security.c | 7 + 37 files changed, 422 insertions(+), 6 deletions(-) create mode 100644 fs/mount_notify.c
next reply other threads:[~2020-08-03 15:28 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-03 15:27 David Howells [this message] 2020-08-03 15:49 ` [GIT PULL] Filesystem Information David Howells 2020-08-03 16:42 ` Miklos Szeredi 2020-08-04 2:15 ` Ian Kent 2020-08-04 14:36 ` Miklos Szeredi 2020-08-05 1:33 ` Ian Kent 2020-08-05 8:00 ` Miklos Szeredi 2020-08-05 11:13 ` Ian Kent 2020-08-05 8:24 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Miklos Szeredi 2020-08-11 13:54 ` Miklos Szeredi 2020-08-11 14:08 ` Al Viro 2020-08-11 14:22 ` Miklos Szeredi 2020-08-11 14:31 ` Al Viro [not found] ` <CAAgocE07=vVKpQhG+rjEGO=NEBKZ02gjg4TRPxECAc+RKrzn=Q@mail.gmail.com> 2020-08-11 14:36 ` Al Viro 2020-08-11 14:36 ` Miklos Szeredi 2020-08-11 14:42 ` Al Viro 2020-08-11 14:47 ` Miklos Szeredi 2020-08-11 15:20 ` Linus Torvalds 2020-08-11 15:30 ` Miklos Szeredi 2020-08-11 16:05 ` Linus Torvalds 2020-08-11 18:49 ` Miklos Szeredi 2020-08-11 19:31 ` Lennart Poettering 2020-08-11 19:50 ` Christian Brauner 2020-08-11 19:39 ` Christian Brauner 2020-08-12 0:53 ` Ian Kent 2020-08-11 15:39 ` Andy Lutomirski 2020-08-11 16:17 ` Casey Schaufler 2020-08-11 16:30 ` Linus Torvalds 2020-08-11 20:28 ` Miklos Szeredi 2020-08-11 20:36 ` Jann Horn 2020-08-11 20:56 ` Miklos Szeredi 2020-08-11 21:17 ` Andy Lutomirski 2020-08-11 21:18 ` Linus Torvalds 2020-08-12 7:23 ` Miklos Szeredi 2020-08-12 14:39 ` Al Viro 2020-08-12 14:46 ` Miklos Szeredi 2020-08-12 15:08 ` Al Viro 2020-08-12 15:13 ` Miklos Szeredi 2020-08-12 16:33 ` Al Viro 2020-08-12 17:16 ` Miklos Szeredi 2020-08-12 17:39 ` Al Viro 2020-08-12 18:33 ` Al Viro 2020-08-12 21:30 ` Al Viro 2020-08-18 9:41 ` Miklos Szeredi 2020-08-18 9:30 ` Miklos Szeredi 2020-08-12 15:22 ` David Howells 2020-08-11 21:20 ` Al Viro 2020-08-11 21:35 ` Casey Schaufler 2020-08-11 16:05 ` Al Viro 2020-08-11 16:09 ` Linus Torvalds 2020-08-11 16:39 ` Al Viro 2020-08-12 10:14 ` Karel Zak 2020-08-12 13:09 ` Miklos Szeredi 2020-08-12 13:33 ` David Howells 2020-08-12 13:54 ` Miklos Szeredi 2020-08-12 0:05 ` David Howells 2020-08-12 7:55 ` Miklos Szeredi 2020-08-12 8:29 ` David Howells 2020-08-12 8:37 ` Miklos Szeredi 2020-08-12 9:43 ` file metadata via fs API Steven Whitehouse 2020-08-12 10:04 ` Miklos Szeredi 2020-08-12 11:28 ` Karel Zak 2020-08-12 12:43 ` Miklos Szeredi 2020-08-13 8:52 ` Karel Zak 2020-08-12 13:06 ` David Howells 2020-08-13 1:01 ` Ian Kent 2020-08-12 18:18 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Linus Torvalds 2020-08-12 19:34 ` file metadata via fs API Steven Whitehouse 2020-08-12 19:50 ` Linus Torvalds 2020-08-13 3:44 ` Ian Kent 2020-08-13 10:36 ` Karel Zak 2020-08-14 7:58 ` Lennart Poettering 2020-08-17 11:32 ` Steven Whitehouse 2020-08-17 17:15 ` Linus Torvalds 2020-08-17 22:44 ` Linus Torvalds 2020-08-18 12:50 ` Miklos Szeredi 2020-08-18 18:51 ` Linus Torvalds 2020-08-18 20:18 ` Miklos Szeredi 2020-08-18 20:53 ` Linus Torvalds 2020-08-21 13:17 ` Miklos Szeredi 2020-08-19 2:29 ` Al Viro 2020-08-13 3:53 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Jeffrey E Altman 2020-08-14 17:05 ` Linus Torvalds 2020-08-18 15:01 ` Jeffrey E Altman 2020-08-14 8:06 ` Lennart Poettering 2020-08-12 13:54 ` David Howells 2020-08-12 14:10 ` Miklos Szeredi 2020-08-12 14:23 ` David Howells 2020-08-03 22:48 ` [GIT PULL] Mount notifications Ian Kent
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=1842689.1596468469@warthog.procyon.org.uk \ --to=dhowells@redhat.com \ --cc=christian@brauner.io \ --cc=jlayton@redhat.com \ --cc=kzak@redhat.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mszeredi@redhat.com \ --cc=nicolas.dichtel@6wind.com \ --cc=raven@themaw.net \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --subject='Re: [GIT PULL] Mount notifications' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).