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...
--
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
