summaryrefslogtreecommitdiff
path: root/tools/unittests/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2026-07-10 11:33:25 +0200
committerChristian Brauner <brauner@kernel.org>2026-08-03 10:08:39 +0200
commit22c879a60d8248f9941e03145edea7cbd44ad864 (patch)
treedaa6237178cc25cae8b940e312d9465fc95f5780 /tools/unittests/git@git.tavy.me:linux.git
parent3ca485a067c650ca8d6d146faae41d130d7324aa (diff)
binfmt_misc: allow removing entries via unlink(2)
Removing a binary type handler requires echoing -1 into its entry file which works but is an odd interface to discover for something that already looks like a plain file in a filesystem. The comment on remove_binfmt_handler() has been suggesting a proper ->unlink() method for years, so add one: unlinking an entry file unhashes the entry from the handler list and removes the file, exactly like writing -1 to it does. The status and register control files refuse removal with EPERM the same way binderfs protects binder-control. Writing -1 keeps working. Permission-wise nothing new is exposed: unlink(2) requires write access to the root directory which is owned by the (user namespace) root with mode 0755, matching the privilege needed to write to the 0644 entry files. The VFS calls ->unlink() with the root inode lock held so the existing writer serialization scheme applies unchanged, and eviction of the unlinked inode drops the entry reference exactly as for the write based removal. Document the new way in admin-guide/binfmt-misc.rst. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-24-a162f7cb58d6@kernel.org Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/unittests/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions