From: Pavel Machek <pavel@suse.cz>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
torvalds@linux-foundation.org,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch
Date: Thu, 9 Oct 2008 14:23:19 +0200 [thread overview]
Message-ID: <20081009122319.GC1623@ucw.cz> (raw)
In-Reply-To: <20081008025209.GO25780@parisc-linux.org>
On Tue 2008-10-07 20:52:09, Matthew Wilcox wrote:
> On Wed, Oct 08, 2008 at 01:35:44PM +1100, Nick Piggin wrote:
> > Right you are. That's the fundamental question. The actual details of
> > the fix and how likely the race is don't really matter until we
> > answer the first question (except to say that the "fix" is never going
> > to be free).
> >
> > We've lasted this long with the current semantics. So the natural
> > reaction to anything that strengthens the semantics now is "why?". If
> > we do that then we can basically never return to the weaker semantics.
> > So there had better be a really good reason.
>
> And it's worth saying that letter-of-the-standard arguments aren't
> necessarily enough. Linux does not honour the POSIX guarantee that
> writes are atomic (if they cross page boundaries, it's not certain).
> This seems like even more of a corner case to me.
We have append-only files, and normal users should not be able to work
around that restriction.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2008-10-09 12:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 5:07 [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch Hisashi Hifumi
2008-10-07 6:43 ` Andi Kleen
2008-10-07 10:11 ` Hisashi Hifumi
2008-10-07 10:29 ` Andi Kleen
2008-10-07 16:27 ` Nick Piggin
2008-10-07 17:50 ` Andrew Morton
2008-10-07 18:59 ` Peter Zijlstra
2008-10-08 2:35 ` Nick Piggin
2008-10-08 2:52 ` Matthew Wilcox
2008-10-09 12:23 ` Pavel Machek [this message]
2008-10-09 12:49 ` Valdis.Kletnieks
2008-10-09 13:01 ` Matthew Wilcox
2008-10-09 13:38 ` Miklos Szeredi
2008-10-09 14:58 ` Linus Torvalds
2008-10-09 17:29 ` Jeremy Fitzhardinge
2008-10-08 4:48 ` Hisashi Hifumi
2008-10-08 5:10 ` Nick Piggin
2008-10-08 5:16 ` Matthew Wilcox
2008-10-08 6:28 ` Andrew Morton
2008-10-08 6:51 ` Peter Zijlstra
2008-10-08 8:32 ` Eric Dumazet
2008-10-08 8:32 ` Eric Dumazet
2008-10-08 8:48 ` Nick Piggin
2008-10-08 9:17 ` Peter Zijlstra
2008-10-09 21:51 ` dcg
2008-10-10 2:25 ` Nick Piggin
2008-10-10 2:25 ` Nick Piggin
2008-10-09 12:16 ` Pavel Machek
2008-10-08 0:40 ` Nick Piggin
2008-10-07 18:00 ` Matthew Wilcox
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=20081009122319.GC1623@ucw.cz \
--to=pavel@suse.cz \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hifumi.hisashi@oss.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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.