VFS locking: f_pos thread-safe ?

[Werner Almesberger]

I'm trying to figure out how all the locking in VFS and friends
works, and I can't quite explain to myself how f_pos is kept
consistent with concurrent readers.

In fact, there might be a violation of atomicity requirements:
e.g. if we take the route sys_read -> vfs_read ->
generic_file_read -> __generic_file_aio_read ->
do_generic_file_read -> do_generic_mapping_read, we don't seem
to be holding any locks. So if I have two threads that start
reading the same fd at the same time, they could retrieve the
same data.

Section 2.9.7 of the "Austin" draft of IEEE Std. 1003.1-200x,
28-JUL-2000, says:

"[...] read( ) [...] shall be atomic with respect to each other
 in the effects specified in IEEE Std. 1003.1-200x when they
 operate on regular files. If two threads each call one of these
 functions, each call shall either see all of the specified
 effects of the other call, or none of them."

I've written a little test program with concurrent readers that
seems to support this observation, i.e. given the following
pseudo-code:

static void *reader(...)
{
    while (read(0,buffer,PAGE_SIZE));
    ...
}

...
    for (...)
	pthread_create(...,reader...);
...

More than one reader may obtain a given page.
The full test program is at
http://www.almesberger.net/misc/tt.tar.gz

Is this a real bug or am I just confused ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@xxxxxxxxxxxxxxx /
/_http://www.almesberger.net/____________________________________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/