From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-fsdevel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: [PATCHES] struct path constification
Date: Sat, 20 Aug 2022 19:10:38 +0100 [thread overview]
Message-ID: <YwEjnoTgi7K6iijN@ZenIV> (raw)
This is mostly whack-a-mole stuff - a bunch of places
are passing struct path pointers around, without bothering
to mark them const, even though they are not going to try
and modify the contents of struct path.
It's a bad practice, since there are invariants along
the lines of "file->f_path stays unchanged open-to-release"
and verifying those can get very unpleasant when you are
forced to take detours down the long call chains that could've
been avoided.
Patches in that pile are independent from each other
and if anyone wants to grab some of them into subsystem's
tree - just say so; I'll be happy to exclude those from the
vfs.git branch if they go into another tree.
Currently they are in vfs.git#work.path; individual
patches in followups.
next reply other threads:[~2022-08-20 18:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-20 18:10 Al Viro [this message]
2022-08-20 18:11 ` Subject: [PATCH 01/11] ->getprocattr(): attribute name is const char *, TYVM Al Viro
2022-08-22 13:51 ` Paul Moore
2022-08-22 14:38 ` Casey Schaufler
2022-08-20 18:12 ` [PATCH 02/11] do_sys_name_to_handle(): constify path Al Viro
2022-08-20 18:12 ` [PATCH 03/11] may_linkat(): " Al Viro
2022-08-20 18:12 ` [PATCH 04/11] fs/notify: " Al Viro
2022-08-23 7:08 ` Matthew Bobrowski
2022-08-20 18:12 ` [PATCH 05/11] overlayfs: " Al Viro
2022-08-20 18:12 ` [PATCH 06/11] do_proc_readlink(): " Al Viro
2022-08-20 18:12 ` [PATCH 07/11] __io_setxattr(): " Al Viro
2022-08-20 18:12 ` [PATCH 08/11] audit_init_parent(): " Al Viro
2022-08-20 18:12 ` [PATCH 09/11] nd_jump_link(): " Al Viro
2022-08-20 18:12 ` [PATCH 10/11] spufs: " Al Viro
2022-08-20 18:12 ` [PATCH 11/11] ecryptfs: " Al Viro
2022-08-26 8:14 ` [PATCHES] struct path constification Christian Brauner
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=YwEjnoTgi7K6iijN@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/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 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).