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?
