From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
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: Tue, 07 Oct 2008 20:59:23 +0200 [thread overview]
Message-ID: <1223405963.26330.83.camel@lappy.programming.kicks-ass.net> (raw)
In-Reply-To: <20081007105056.16d9e785.akpm@linux-foundation.org>
On Tue, 2008-10-07 at 10:50 -0700, Andrew Morton wrote:
> On Wed, 8 Oct 2008 03:27:44 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > So.. is everyone agreed that corrupting f_pos is a bad thing? (serious
> > question) If so, then we should get something like this merged sooner
> > rather than later.
>
> - two threads/processes sharing the same fd
>
> - both appending the same fd
>
> - both hit the small race window right around the time when the file
> flips over a multiple of 4G.
>
> It's pretty damn improbable, and I think we can afford to spend the
> time to get this right in 2.6.29.
The whole point is that such usage is outside the specification and thus
we don't strictly need to fix this.
So the question Nick is asking is, do we want to slow down the kernel
for a few broken user-space applications. Esp. since the race doesn't
affect anybody else except the broken users of the file descriptor.
IMHO not worth fixing..
next prev parent reply other threads:[~2008-10-07 18:59 UTC|newest]
Thread overview: 28+ 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 [this message]
2008-10-08 2:35 ` Nick Piggin
2008-10-08 2:52 ` Matthew Wilcox
2008-10-09 12:23 ` Pavel Machek
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: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-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=1223405963.26330.83.camel@lappy.programming.kicks-ass.net \
--to=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=nickpiggin@yahoo.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox