From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andi Kleen <andi@firstfloor.org>
Cc: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch
Date: Wed, 8 Oct 2008 03:27:44 +1100 [thread overview]
Message-ID: <200810080327.44530.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20081007102942.GE20740@one.firstfloor.org>
On Tuesday 07 October 2008 21:29, Andi Kleen wrote:
> > Maybe cmpxchg8b is good for i486 or later x86, but i386 or other
> > architectures that do not have similar instruction needs some locking
> > primitive. I think lazy
>
> We have a cmpxchg emulation on 386. That works because only UP 386s are
> supported, so it can be done in software.
>
> > seqlock is one option for making file->f_pos access atomic.
>
> The question is if it's the right option. At least all the common
> operations on fds (read/write) are all writers, not readers.
Common operations are read, do something, write. So seqlocks then cost
one atomic operation, a couple of memory barriers (all noops on x86),
and some predictable branches etc.
cmpxchg based would require 2 lock ; cmpxchg8b on 32-bit. Fairly heavy.
Also I don't think we have generic accessors to do this, so I think
that is for another project.
Anyway, I think importantly this creates some usable accessors for the
f_pos problem. I think we actually need to touch a _lot_ of code to
cover all f_pos accesses in the kernel, but I guess this gets the ball
rolling.
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.
next prev parent reply other threads:[~2008-10-07 16:28 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 [this message]
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
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=200810080327.44530.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hifumi.hisashi@oss.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.