[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YS+dstZ3xfcLxhoB@zeniv-ca.linux.org.uk>
Date: Wed, 1 Sep 2021 15:35:14 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Dmitry Kadashev <dkadashev@...il.com>
Cc: Jens Axboe <axboe@...nel.dk>,
Christoph Hellwig <hch@...radead.org>,
Stephen Brennan <stephen.s.brennan@...cle.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] namei: get rid of unused filename_parentat()
On Wed, Sep 01, 2021 at 03:30:56PM +0000, Al Viro wrote:
> On Wed, Sep 01, 2021 at 10:00:40PM +0700, Dmitry Kadashev wrote:
> > After the switch of kern_path_locked() to __filename_parentat() (to
> > address use after free bug) nothing is using filename_parentat(). Also,
> > filename_parentat() is inherently buggy: the "last" output arg
> > always point to freed memory.
> >
> > Drop filename_parentat() and rename __filename_parentat() to
> > filename_parentat().
>
> I'd rather fold that into previous patch.
>
> And it might be better to fold filename_create() into its 2 callers
> and rename __filename_create() as well.
>
> Let me poke around a bit...
BTW, if you look at the only caller of filename_lookup() outside of
fs/namei.c, you'll see this:
f->refcnt++; /* filename_lookup() drops our ref. */
ret = filename_lookup(param->dirfd, f, flags, _path, NULL);
IOW, that thing would be better off with calling the current
__filename_lookup().
Might be better to rename filename_lookup to something different,
turn __filename_lookup() into filename_lookup() and use _that_ in
fs/fs_parser.c...
Powered by blists - more mailing lists