[lkml]   [1999]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: event->global_event
On Saturday December 18, wrote:
> Alan renamed "event" to "global_event" in 2.2.14pre, IMHO we should do
> the same in 2.3.x.
> And: AFAICS, "event" is used for
> * inode->i_generation in fs/ext2/ialloc.c
> This one is new, and it's obviously wrong: everyone else uses "++event",
> but this function uses "event++". AFAICS we should replace it with an
> internal, ext2 specific counter.

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.034 / U:6.928 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site