linux-kernel - Re: [RESEND] [PATCH] VFS: make file->f

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/