netdev - Re: [PATCH][RFC] don't bother with path_get()/path_put() in unix_open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250714150412.GF1880847@ZenIV>
Date: Mon, 14 Jul 2025 16:04:12 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Christian Brauner <brauner@...nel.org>
Cc: Kuniyuki Iwashima <kuniyu@...gle.com>, linux-fsdevel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH][RFC] don't bother with path_get()/path_put() in
 unix_open_file()

On Mon, Jul 14, 2025 at 10:24:11AM +0200, Christian Brauner wrote:
> On Sat, Jul 12, 2025 at 06:38:33AM +0000, Kuniyuki Iwashima wrote:
> > From: Al Viro <viro@...iv.linux.org.uk>
> > Date: Sat, 12 Jul 2025 06:41:57 +0100
> > > Once unix_sock ->path is set, we are guaranteed that its ->path will remain
> > > unchanged (and pinned) until the socket is closed.  OTOH, dentry_open()
> > > does not modify the path passed to it.
> > > 
> > > IOW, there's no need to copy unix_sk(sk)->path in unix_open_file() - we
> > > can just pass it to dentry_open() and be done with that.
> > > 
> > > Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
> > 
> > Sounds good.  I confirmed vfs_open() copies the passed const path ptr.
> > 
> > Reviewed-by: Kuniyuki Iwashima <kuniyu@...gle.com>
> 
> I can just throw that into the SCM_PIDFD branch?

Fine by me; the thing is, I don't have anything else in the area at the moment
(and won't until -rc1 - CLASS(get_unused_fd) series will stray there, but
it's not settled enough yet, so it's definitely the next cycle fodder).

So if you (or netdev folks) already have anything going on in the af_unix.c,
I've no problem with that thing going there.