On Tue, May 15, 2018 at 09:52:37AM +0900, Tetsuo Handa wrote:
> > On Tue, May 15, 2018 at 09:27:35AM +0900, Tetsuo Handa wrote:
> > > Eric Biggers wrote:
> > > > > I'm not following, since generic_shutdown_super() only calls ->put_super() if
> > > > > ->s_root is set, which only happens at the end of shmem_fill_super(). Isn't the
> > > > > real problem that s_shrink is registered too early, causing super_cache_count()
> > > > > and shmem_unused_huge_count() to potentially run before shmem_fill_super() has
> > > > > completed? Or alternatively, the problem is that super_cache_count() doesn't
> > > > > check for SB_ACTIVE.
> > > > >
> > > >
> > > > Coincidentally, this is already going to be fixed by commit 79f546a696bff259
> > > > ("fs: don't scan the inode cache before SB_BORN is set") in vfs/for-linus.
> > > >
> > >
> > > Just an idea, but if shrinker registration is too early, can't we postpone it
> > > like below?
> >
> > Wonderful. And when ->mount() returns you a subtree of the same filesystem again,
> > that will do what, exactly?
> >
> Can't we detect it via list_empty(&sb->s_shrink.list) test
> before calling register_shrinker_prepared(&sb->s_shrink) ?
What for? Seriously, what's the benefit of doing that in such a convoluted way?
Avoiding a trivial check in super_cache_count()? The same check we normally
do in places where we are not holding an active reference to superblock and
want to make sure it's alive, at that...
