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
