On Thu, Mar 10, 2016 at 03:46:43AM +0000, Drokin, Oleg wrote: > > Wait a minute. If it's hashed, has the right name and the right parent, > > why the hell are we calling ->lookup() on a new dentry in the first place? > > Why hadn't we simply picked it from dcache? > > This is because of the trickery we do in the d_compare. > our d_compare looks at the "invalid" flag and if it's set, returns "not matching", > triggering the lookup instead of revalidate. > This makes revalidate simple and fast. > (We used to have a complicated revalidate with a lot of code duplication with > lookup in order to be able to query the server and pass all sorts of data there > and it was nothing but trouble). *Ugh*... That's really nasty. We certainly could make d_exact_match() accept unhashed ones and make rehashing conditional (NFS doesn't pull anything similar, so it won't care), but your ->d_revalidate() has exact same problem as ext4_d_revalidate() one mentioned upthread - there's no warranty that dentry->d_parent will stay stable. We are *NOT* guaranteed locked parent when ->d_revalidate() is called, or we would have to lock every damn directory on the way through the pathname resolution. Moreover, ->d_revalidate() really can overlap with rename(2). -- 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
