[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.028 / U:247.648 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site