That was me. ++event would be more consistant, but it wouldn't
affect correctness.
ext2 basically needs some low-grade noise to uniquify re-allocated
inodes so that the filehandle that knfsd uses will be different each
time an inode is deleted and re-allocated.
Certainly an ext2 specific counter could do the job, but it isn't
really necessary - any lowgrade noise would do, and event++ (or
++event) seemed to fit the bill perfectly -- the apparent semantics of
"++event" is "this is a different number every time you look at it,
but there is no guarantee how different" which is about right.
>
> * inode->i_version, file->f_version.
> a) files: it's nowhere read, but it's updated by a few functions (eg
> default_llseek(), but not by generic_file_read() although both functions
> modify the file pionter)
>
> ---> it's superflous, remove it!
Would removing it for files but leaving it for directories just add
lots of extra conditionals?
>
> b) directories: it's required to protect from readdir()/unlink() races.
>
> Btw, AFAICS, then SMP protection for the read-ahead information in
> generic_file_read() is missing. I don't know if this is dangerous.
> Perhaps we should add a spinlock to each filp?
If two separate processes (or threads) are reading on the same file,
then weird things happen anyway. f_pos is not updated atomically so
if, for example you have:
fd = open("afile", O_RDONLY);
if (fork()) {
read(fd, buf, 1024);
...
} else {
read(fd, buf, 1024);
}
it is quite possible for both processes to read the first block of the
file, or maybe one with get the second block, and who knows where the
file pointer will be at the end.
Basically, if two threads are doing reads or writes on the same "file"
structure, then they had better be co-ordinating themselves - there is
nothing much that the kernel can do to help. (using pread, pwrite
would work safely).
But the name "global_event" sounds like a great idea. Send a patch to
Linus?
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/