Re: system panic while dentry reference count overflow

[Al Viro <viro@zeniv.linux.org.uk>]

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@zeniv.linux.org.uk> 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...