[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1223448711.1378.16.camel@lappy.programming.kicks-ass.net>
Date: Wed, 08 Oct 2008 08:51:51 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Hisashi Hifumi <hifumi.hisashi@....ntt.co.jp>
Cc: Nick Piggin <nickpiggin@...oo.com.au>,
torvalds@...ux-foundation.org,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Theodore Ts'o <tytso@....edu>
Subject: Re: [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit
arch
On Wed, 2008-10-08 at 13:48 +0900, Hisashi Hifumi wrote:
> Simultaneous access by two or more writer can corrupt file content,
> so this case needs some locks(flock or fcntl) to preserve synchronization
> of file content. This is responsibility of user-space application.
> But file->f_pos race issue can occur even if multiple threads just read
> simultaneously. I think this is not responsibility of user-space application.
> To avoid this currently, an application needs some locks to protect file offset
> even if it just read a file. So I think f_pos race should be fixed.
Just to add to all those who already said you're wrong :-)
You're wrong, if two threads would like to read the same file they
either dup() the fd or open() the file twice. There is absolutely no
valid reason to have two threads read from the same fd without
synchronising their access to it - never.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists