From: Matthew Wilcox <willy@infradead.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Xavier Roche <xavier.roche@algolia.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: race between vfs_rename and do_linkat (mv and link)
Date: Tue, 15 Feb 2022 16:17:11 +0000 [thread overview]
Message-ID: <YgvSB6CKAhF5IXFj@casper.infradead.org> (raw)
In-Reply-To: <YgvPbljmJXsR7ESt@zeniv-ca.linux.org.uk>
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.
>
> Does POSIX actually make any promises in that area? That would affect
> how high a cost we ought to pay for that - I agree that it would be nicer
> to have atomicity from userland point of view, but there's a difference
> between hard bug and QoI issue.
As I understand the original report, it relies on us hitting the nlink ==
0 at exactly the wrong moment. Can't we just restart the entire path
resolution if we find a target with nlink == 0? Sure, it's a lot of
extra work, but you've got to be trying hard to hit it in the first place.
next prev parent reply other threads:[~2022-02-15 16:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 21:07 fs: race between vfs_rename and do_linkat (mv and link) Xavier Roche
2022-02-15 9:56 ` Miklos Szeredi
2022-02-15 13:37 ` Al Viro
2022-02-15 16:06 ` Al Viro
2022-02-15 16:17 ` Matthew Wilcox [this message]
2022-02-15 16:20 ` Al Viro
2022-02-16 9:28 ` Miklos Szeredi
2022-02-16 10:28 ` Miklos Szeredi
2022-02-16 13:18 ` Xavier Roche
2022-02-16 13:37 ` Miklos Szeredi
2022-02-18 15:37 ` Miklos Szeredi
2022-02-15 16:18 ` Al Viro
2022-02-15 16:56 ` Xavier Roche
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=YgvSB6CKAhF5IXFj@casper.infradead.org \
--to=willy@infradead.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
--cc=xavier.roche@algolia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.