From: Al Viro <viro@ZenIV.linux.org.uk>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write
Date: Wed, 21 Nov 2018 04:54:41 +0000 [thread overview]
Message-ID: <20181121045440.GM32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20181121024400.4346-1-devel@etsukata.com>
On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> Some file systems (including ext4, xfs, ramfs ...) have the following
> problem as I've described in the commit message of the 1/4 patch.
>
> The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek")
> removed almost all locks in llseek() including SEEK_END. It based on the
> idea that write() updates size atomically. But in fact, write() can be
> divided into two or more parts in generic_perform_write() when pos
> straddles over the PAGE_SIZE, which results in updating size multiple
> times in one write(). It means that llseek() can see the size being
> updated during write().
And? Who has ever promised anything that insane? write(2) can take an arbitrary
amount of time; another process doing lseek() on independently opened descriptor
is *not* going to wait for that (e.g. page-in of the buffer being written, which
just happens to be mmapped from a file on NFS over RFC1149 link).
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Eiichi Tsukata <devel@etsukata.com>
Cc: andi@firstfloor.org, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Bob Peterson <rpeterso@redhat.com>,
Andreas Gruenbacher <agruenba@redhat.com>,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com,
linux-unionfs@vger.kernel.org
Subject: Re: [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write
Date: Wed, 21 Nov 2018 04:54:41 +0000 [thread overview]
Message-ID: <20181121045440.GM32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20181121024400.4346-1-devel@etsukata.com>
On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> Some file systems (including ext4, xfs, ramfs ...) have the following
> problem as I've described in the commit message of the 1/4 patch.
>
> The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek")
> removed almost all locks in llseek() including SEEK_END. It based on the
> idea that write() updates size atomically. But in fact, write() can be
> divided into two or more parts in generic_perform_write() when pos
> straddles over the PAGE_SIZE, which results in updating size multiple
> times in one write(). It means that llseek() can see the size being
> updated during write().
And? Who has ever promised anything that insane? write(2) can take an arbitrary
amount of time; another process doing lseek() on independently opened descriptor
is *not* going to wait for that (e.g. page-in of the buffer being written, which
just happens to be mmapped from a file on NFS over RFC1149 link).
next prev parent reply other threads:[~2018-11-21 4:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 2:43 [Cluster-devel] [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write Eiichi Tsukata
2018-11-21 2:43 ` Eiichi Tsukata
2018-11-21 2:43 ` [Cluster-devel] [PATCH v1 1/4] vfs: " Eiichi Tsukata
2018-11-21 2:43 ` Eiichi Tsukata
2018-11-21 2:43 ` [Cluster-devel] [PATCH v1 2/4] ext4: " Eiichi Tsukata
2018-11-21 2:43 ` Eiichi Tsukata
2018-11-21 2:43 ` [Cluster-devel] [PATCH v1 3/4] f2fs: " Eiichi Tsukata
2018-11-21 2:43 ` Eiichi Tsukata
2018-11-21 9:23 ` [Cluster-devel] " Christoph Hellwig
2018-11-21 9:23 ` Christoph Hellwig
2018-11-22 5:42 ` [Cluster-devel] " Eiichi Tsukata
2018-11-22 5:42 ` Eiichi Tsukata
2018-11-21 2:44 ` [Cluster-devel] [PATCH v1 4/4] overlayfs: " Eiichi Tsukata
2018-11-21 2:44 ` Eiichi Tsukata
2018-11-21 4:54 ` Al Viro [this message]
2018-11-21 4:54 ` [PATCH v1 0/4] fs: " Al Viro
2018-11-22 5:40 ` [Cluster-devel] " Eiichi Tsukata
2018-11-22 5:40 ` Eiichi Tsukata
2018-11-22 7:06 ` [Cluster-devel] " Al Viro
2018-11-22 7:06 ` Al Viro
2018-11-26 2:54 ` [Cluster-devel] " Eiichi Tsukata
2018-11-26 2:54 ` Eiichi Tsukata
2018-11-26 2:54 ` Eiichi Tsukata
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=20181121045440.GM32577@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
/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.