On Friday 14 January 2011, 05:01:37 Nick Piggin wrote: > On Fri, Jan 14, 2011 at 2:38 PM, J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote: > > When open(2) without O_DIRECTORY opens an existing dir, it should > > return EISDIR. In do_last(), the variable 'error' is initialized > > EISDIR, but it is changed by d_revalidate() which returns any > > positive to represent 'the target dir is valid.' > > Should we keep and return the initialized 'error' in this case. > > Great, thank you very much. I just changed a few variable names but > applied it. Would you please add you Signed-off-by: on patches from > now on? > > Good reviewing work. Are you finding these by review or testing? I > think ltptests on an nfs mount should find this kind of bug... which > I should do. Nick, Junjiro is well known as a very smart (and|but) humble guy in the kernel niche of layered filesystems. Be assured, that almost every live distribution (one, that is runnable from RO media directly) _relies_ on his work: aufs (http://aufs.sourceforge.net/) to get the job done. Also many diskless setups (as do mine) relies on aufs. It's a real pity, that all other approaches to layered filesystems (or filesystem unification, overlay filesystems), that are done by others, are either - technically inferior - restricted in usage scenarios - simply unfinished but get more attention in the kernel guild. All, that Junjiro's approach takes is exporting a handful of symbols in order to be able to build it as a module also (and the number decreases as other lately merged subsystems do need them as well, i.e. apparmor). That's all. Layered filesystems are a killer feature, that could have been in the kernel for years, but is still missing for hard to follow (e.g. political, emotional) reasons. There are many interesting things, that can be done with layered filesystems, hard to archive up to impossible to be done otherwise). Sadly, Pete -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
