On Oct 21, 2014, at 3:30 PM, Al Viro wrote: > On Tue, Oct 21, 2014 at 05:02:10AM +0100, Al Viro wrote: > >> 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... > > Next one: is there any codepath that could lead to ll_md_blocking_ast() > before we get ->s_root assigned? IOW, what's > inode->i_sb->s_root != NULL && > in there about? Pure paranoia or something more serious? Because from the > look of the call chains leading to that, having them hit before the superblock > has been set up seems to be risky... I bet it's pure paranoia. I tracked this bit of code all the way back into 2003 in this unchanged form.-- 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
