[lkml]   [2005]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] atomic create+open
    to den 06.10.2005 Klokka 20:49 (+0200) skreiv Miklos Szeredi:

    > For simplicity case let's omit the creation of simlink, just say, the
    > file is removed.
    > So NFS calls have_submounts(), which returns true.
    > Then the bind is umounted. Nothing prevents this happening
    > concurrently with the lookup.
    > Then the file is removed on the server.
    > When open_namei() gets around to following the mounts, it is not there
    > any more, so the dentry for /mnt/foo (the NFS one is returned) and
    > NFS's ->open is called on the file, which returns -ENOENT. But
    > open(..., O_CREAT, ...) should never return -ENOENT.

    ...and so the VFS can recognise the case, and be made to retry the
    A more difficult race to deal with occurs if you allow a mount while
    inside d_revalidate(). In that case NFS can end up opening the wrong
    Both these two races could, however, be fixed by moving the
    __follow_mount() in open_namei() inside the section that is protected by
    the parent directory i_sem.

    In any case, all you are doing here is showing that the situation w.r.t.
    mount races and lookup+create+open is difficult. I see nothing that
    convinces me that a special atomic create+open will help to resolve
    those races.
    Nor do I see that adding a special atomic create+open will help me avoid
    intents for the case of atomic lookup+open(). As far as I'm concerned,
    the case of lookup+create+open is just a special case of lookup+open.


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

     \ /
      Last update: 2005-10-06 21:20    [W:0.022 / U:14.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site