On Tue, Oct 21, 2014 at 03:46:02AM +0000, Drokin, Oleg wrote: > > a) what protects ->d_name in ll_intent_file_open()? It copies > > ->d_name.name and ->d_name.len into local variables and proceeds to > > use those; what's to guarantee that dentry won't get hit with d_move() > > halfway through that? None of the locks that would give an exclusion > > against d_move() appear to be held… > > You are right. We hit something very similar not too long ago. > > > > b) what stabilizes *dentryp->d_name in do_statahead_enter()? > Same as above. > All of that would go away once we get rid of the wrapper and unroll the > vfs ops. > > Hopefully this makes at least some sense to you. OK... I'd gone and ripped some of that stuff out today; see if what's in vfs.git#for-oleg makes sense... Another question: what's wrong with d_splice_alias() or d_materialise_unique()? I.e. why do we need ll_splice_alias()? I have patches in local queue (soon to show up in for-next) that merge d_splice_alias() and d_materialise_unique(), essentially teaching the former to deal with one case d_materialise_unique() can handle while d_splice_alias() couldn't. If you need something not covered by those, it would be interesting to find out if it would make sense to fold _that_ into d_splice_alias() as well... -- 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
