[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegv03YpTPiDnLwbaewQX_KZws5nutays+vso2BVJ1v1+TA@mail.gmail.com>
Date: Wed, 16 Feb 2022 10:28:20 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Matthew Wilcox <willy@...radead.org>,
Xavier Roche <xavier.roche@...olia.com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: race between vfs_rename and do_linkat (mv and link)
On Tue, 15 Feb 2022 at 17:20, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Tue, Feb 15, 2022 at 04:17:11PM +0000, Matthew Wilcox wrote:
> > On Tue, Feb 15, 2022 at 04:06:06PM +0000, Al Viro wrote:
> > > On Tue, Feb 15, 2022 at 01:37:40PM +0000, Al Viro wrote:
> > > > On Tue, Feb 15, 2022 at 10:56:29AM +0100, Miklos Szeredi wrote:
> > > >
> > > > > Doing "lock_rename() + lookup last components" would fix this race.
> > >
> > > "Fucking ugly" is inadequate for the likely results of that approach.
> > > It's guaranteed to be a source of headache for pretty much ever after.
So this is a fairly special situation. How about adding a new rwsem
(could possibly be global or per-fs)?
- acquired for read in lock_rename() before inode locks
- acquired for write in do_linkat before inode locks, but only on retry
Thanks,
Miklos
Powered by blists - more mailing lists