Re: [PATCH RFC] kernel/locking, fs/direct-io: Introduce and use down_write_nolockdep()

[Matthew Wilcox <willy@infradead.org>]

On Fri, Oct 26, 2018 at 11:11:18AM -0700, Bart Van Assche wrote:
> On Fri, 2018-10-26 at 10:43 -0700, Matthew Wilcox wrote:
> > On Fri, Oct 26, 2018 at 09:49:05AM -0700, Bart Van Assche wrote:
> > > diff --git a/mm/rmap.c b/mm/rmap.c
> > > index 1e79fac3186b..2a953d3b7431 100644
> > > --- a/mm/rmap.c
> > > +++ b/mm/rmap.c
> > > @@ -81,6 +81,7 @@ static inline struct anon_vma *anon_vma_alloc(void)
> > >  
> > >  	anon_vma = kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL);
> > >  	if (anon_vma) {
> > > +		init_rwsem(&anon_vma->rwsem);
> > >  		atomic_set(&anon_vma->refcount, 1);
> > >  		anon_vma->degree = 1;	/* Reference for first vma */
> > >  		anon_vma->parent = anon_vma;
> > 
> > Why is this needed?  The anon_vma_ctor() already calls init_rwsem().
> > 
> > (I suspect this is one of those ctors that isn't actually useful and
> > should be inlined into anon_vma_alloc())
> 
> Without that call I noticed that the "nolockdep" variable was sometimes set
> when down_write() got called. Does that mean that it can happen that an
> anon_vma structure is freed without releasing anon_vma->rwsem?

How strange.  The only call to down_write_nolockdep() you added (in this
patch) was for the inode->i_mutex.  So how could that possibly affect
the anon_vma->rwsem?  Are you seeing some kind of corruption here?

Maybe try initialising ->nolockdep with some 32-bit magic value,
and reporting if it's not 0 or the magic value will lead to some kind
of insight?