Re: [PATCH v6 3/3] exfat: reclaim name filters under memory pressure

[Namjae Jeon]

> +static unsigned long
> +exfat_name_filter_scan_objects(struct shrinker *shrinker,
> +                              struct shrink_control *sc)
> +{
> +       struct exfat_sb_info *sbi = shrinker->private_data;
> +       unsigned long freed = 0;
> +
> +       /* Avoid reclaim recursion from a GFP_NOFS allocation under s_lock. */
> +       if (!mutex_trylock(&sbi->s_lock)) {
> +               sc->nr_scanned = 0;
> +               return SHRINK_STOP;
> +       }
> +
> +       while (freed < sc->nr_to_scan) {
> +               struct exfat_inode_info *ei;
> +               unsigned long *filter;
> +
> +               spin_lock(&sbi->name_filter_lock);
> +               if (list_empty(&sbi->name_filter_lru)) {
> +                       spin_unlock(&sbi->name_filter_lock);
> +                       break;
> +               }
> +
> +               ei = list_first_entry(&sbi->name_filter_lru,
> +                                     struct exfat_inode_info,
> +                                     name_filter_lru);
> +               filter = exfat_name_filter_detach_locked(sbi, ei);
> +               spin_unlock(&sbi->name_filter_lock);
> +
> +               kvfree(filter);
> +               freed++;
> +               cond_resched();
> +       }
> +
> +       mutex_unlock(&sbi->s_lock);
> +       sc->nr_scanned = freed;
When the LRU becomes empty before nr_to_scan is satisfied, this
reports nr_scanned == 0. do_shrink_slab() subtracts only nr_scanned
from total_scan and retries while total_scan >= freeable. For example,
with one filter and reclaim priority 0, the first scan frees the
filter, but the next scan makes no progress and the loop can run
forever. Could the empty-list path return SHRINK_STOP or otherwise
ensure the remaining scan budget is consumed?