On Sat, Jun 29, 2019 at 08:06:24PM +0100, Al Viro wrote:
> On Sat, Jun 29, 2019 at 05:38:03AM +0100, Al Viro wrote:
>
> > PS: the problem is not gone in the next iteration of the patchset in
> > question. The patch I'm proposing (including dput_to_list() and _ONLY_
> > compile-tested) follows. C
On Sat, Jun 29, 2019 at 11:29:45PM +0100, Al Viro wrote:
> Like this (again, only build-tested):
... and with obvious braino fixed,
Teach shrink_dcache_parent() to cope with mixed-filesystem shrink lists
Currently, running into a shrink list that contains dentries from different
filesystems can
On Sat, Jun 29, 2019 at 08:06:24PM +0100, Al Viro wrote:
> I wonder if after the "no evictable candidates, but something
> on other's shrink lists" we ought to do something along the
> lines of
> rcu_read_lock
> walk it, doing
> if dentry has zero refcount
>
On Sat, Jun 29, 2019 at 05:38:03AM +0100, Al Viro wrote:
> PS: the problem is not gone in the next iteration of the patchset in
> question. The patch I'm proposing (including dput_to_list() and _ONLY_
> compile-tested) follows. Comments?
FWIW, there's another unpleasantness in the whole thing.
On Sat, Jun 29, 2019 at 05:08:44AM +0100, Al Viro wrote:
> > The reason we don't hit that problem with regular memory shrinker is
> > this:
> > unregister_shrinker(&s->s_shrink);
> > fs->kill_sb(s);
> > in deactivate_locked_super(). IOW, shrinker for this fs is gone
On Thu, Apr 11, 2019 at 10:02:00PM +0100, Al Viro wrote:
> Aaaarrgghhh... No, we can't. Look: we get one candidate dentry in isolate
> phase. We put it into shrink list. umount(2) comes and calls
> shrink_dcache_for_umount(), which calls shrink_dcache_parent(root).
> In the meanwhile, shrink_d
On Thu, Apr 11, 2019 at 05:47:46AM +0100, Al Viro wrote:
> Note, BTW, that umount coming between isolate and drop is not a problem;
> it call shrink_dcache_parent() on the root. And if shrink_dcache_parent()
> finds something on (another) shrink list, it won't put it to the shrink
> list of its o
On Thu, Apr 11, 2019 at 05:47:46AM +0100, Al Viro wrote:
> The reason for that dance is the locking - shrink list belongs to whoever
> has set it up and nobody else is modifying it. So __dentry_kill() doesn't
> even try to remove the victim from there; it does all the teardown
> (detaches from in
On Thu, Apr 11, 2019 at 05:47:46AM +0100, Al Viro wrote:
> On Thu, Apr 11, 2019 at 12:48:21PM +1000, Tobin C. Harding wrote:
>
> > Oh, so putting entries on a shrink list is enough to pin them?
>
> Not exactly pin, but __dentry_kill() has this:
> if (dentry->d_flags & DCACHE_SHRINK_LIST)
On Thu, Apr 11, 2019 at 12:48:21PM +1000, Tobin C. Harding wrote:
> Oh, so putting entries on a shrink list is enough to pin them?
Not exactly pin, but __dentry_kill() has this:
if (dentry->d_flags & DCACHE_SHRINK_LIST) {
dentry->d_flags |= DCACHE_MAY_FREE;
On Thu, Apr 11, 2019 at 03:33:22AM +0100, Al Viro wrote:
> On Thu, Apr 11, 2019 at 11:34:40AM +1000, Tobin C. Harding wrote:
> > +/*
> > + * d_isolate() - Dentry isolation callback function.
> > + * @s: The dentry cache.
> > + * @v: Vector of pointers to the objects to isolate.
> > + * @nr: Number
On Thu, Apr 11, 2019 at 11:34:40AM +1000, Tobin C. Harding wrote:
> +/*
> + * d_isolate() - Dentry isolation callback function.
> + * @s: The dentry cache.
> + * @v: Vector of pointers to the objects to isolate.
> + * @nr: Number of objects in @v.
> + *
> + * The slab allocator is holding off frees
12 matches
Mail list logo
