On Tue, May 07, 2019 at 01:47:31PM -0700, Linus Torvalds wrote: > On Tue, May 7, 2019 at 12:55 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > Provided that lockref.c is updated accordingly (look at e.g. > > lockref_get_not_zero()). > > Yeah, we should likely just make this all a lockref feature. > > The dcache is *almost* the only user of lockrefs. We've got them in > gfs2 too, but that looks like it would be perfectly happy with the > same model. > > > lockref_get_not_zero() hitting dead dentry is not abnormal, > > so we'd better not complain in such case... BTW, wouldn't that WARN_ON() > > in dget() belong in lockref_get()? > > Yeah. OK... Lockref parts aside, I suspect that the right sequence would be * make d_alloc() and d_alloc_cursor() check for excessive growth of parent's refcount and fail if it's about to occur. That will result in -ENOMEM for now, if we want another errno value, we can follow with making d_alloc() return ERR_PTR() on failure (instead of NULL) * lift the increment of new parent's refcount into the callers of __d_move(..., false) * make the callers in d_splice_alias() fail if refcount is about to overflow * add a reference-consuming variant of d_move() * switch d_move() callers to that one by one, lifting the refcount increment into those, with bailout on overflow * make complete_walk() check for overflow, bail out if it happens. * ditto for clone_mnt(). That would take care of the majority of long-term references; then we'll see what's left...
