linux-kernel - Re: [PATCH 1/2] vmscan: fix initial shrinker size handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20110822143006.60f4b560.akpm@linux-foundation.org>
Date:	Mon, 22 Aug 2011 14:30:06 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH 1/2] vmscan: fix initial shrinker size handling

On Mon, 22 Aug 2011 14:17:21 +0300
Konstantin Khlebnikov <khlebnikov@...nvz.org> wrote:

> Shrinker function can returns -1, it means it cannot do anything without a risk of deadlock.
> For example prune_super() do this if it cannot grab superblock refrence, even if nr_to_scan=0.
> Currenly we interpret this like ULONG_MAX size shrinker, evaluate total_scan according this,
> and next time this shrinker can get really big pressure. Let's skip such shrinkers instead.

Yes, that looks like a significant oversight.

> Also make total_scan signed, otherwise check (total_scan < 0) below never works.

Hopefully a smaller oversight.

> ---
>  mm/vmscan.c |    9 ++++++---
>  1 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 29b3612..f174561 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -248,14 +248,18 @@ unsigned long shrink_slab(struct shrink_control *shrink,
>  
>  	list_for_each_entry(shrinker, &shrinker_list, list) {
>  		unsigned long long delta;
> -		unsigned long total_scan;
> -		unsigned long max_pass;
> +		long total_scan;
> +		long max_pass;
>  		int shrink_ret = 0;
>  		long nr;
>  		long new_nr;
>  		long batch_size = shrinker->batch ? shrinker->batch
>  						  : SHRINK_BATCH;
>  
> +		max_pass = do_shrinker_shrink(shrinker, shrink, 0);
> +		if (max_pass <= 0)
> +			continue;
> +
>  		/*
>  		 * copy the current shrinker scan count into a local variable
>  		 * and zero it so that other concurrent shrinker invocations
> @@ -266,7 +270,6 @@ unsigned long shrink_slab(struct shrink_control *shrink,
>  		} while (cmpxchg(&shrinker->nr, nr, 0) != nr);
>  
>  		total_scan = nr;
> -		max_pass = do_shrinker_shrink(shrinker, shrink, 0);
>  		delta = (4 * nr_pages_scanned) / shrinker->seeks;
>  		delta *= max_pass;
>  		do_div(delta, lru_pages + 1);

Why was the shrinker call moved to before the alteration of shrinker->nr?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/