Re: [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 08 Oct 2008 13:48:10 +0900 Hisashi Hifumi <hifumi.hisashi@xxxxxxxxxxxxx> wrote:

> 
> At 11:35 08/10/08, Nick Piggin wrote:
> >On Wednesday 08 October 2008 05:59, Peter Zijlstra wrote:
> >>
> >> 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.
> >
> >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).
> 
> 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.

But how could that userspace code possibly be reliable even if f_pos
updates were atomic?  The two threads/processes will still read
either the same data, or one will get "A" and the other will get "B" or
one will get "B" and the other will get "A".

And when that application gets fixed, so too does this f_pos problem?

 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux