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]
Date:	Thu, 28 Jul 2011 11:19:43 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Alex Shi <alex.shi@...el.com>
Cc:	minchan.kim@...il.com, stable@...nel.org,
	linux-kernel@...r.kernel.org, andrea@...share.com,
	tim.c.chen@...el.com, shaohua.li@...el.com
Subject: Re: [PATCH] kswapd: assign new_order and new_classzone_idx after
 wakeup in sleeping

On Thu, Jul 28, 2011 at 04:11:28PM +0800, Alex Shi wrote:
> There 2 place to read pgdat in kswapd. One is return from a successful
> balance, another is waked up from sleeping. But the new_order and
> new_classzone_idx are not assigned after kswapd_try_to_sleep(), that
> will cause a bug in the following scenario.
> 
> After the last time successful balance, kswapd goes to sleep. So the
> new_order and new_classzone_idx were assigned to 0 and MAX-1 since there
> is no new wakeup during last time balancing. Now, a new wakeup came and
> finish balancing successful with order > 0. But since new_order is still
> 0, this time successful balancing were judged as a failed balance. so,
> if there is another new wakeup coming during balancing, kswapd cann't
> read this and still want to try to sleep. And if the new wakeup is a
> tighter request, kswapd may goes to sleep, not to do balancing. That is
> incorrect.
> 
> So, to avoid above problem, the new_order and new_classzone_idx need to
> be assigned for later successful comparison.
> 

Other than a different changelog, this is identical to
https://lkml.org/lkml/2011/6/30/157 so

Acked-by: Mel Gorman <mgorman@...e.de>

It won't be merged to -stable until it goes to mainline though so
minimally you need to post this to linux-mm.

For -stable, you should explain why it is a candidate. I didn't push
the patch at the time because user problems were already resolved
and I wanted the merged for 3.0 before revisiting it. What problem
did you observe without this patch? With the lack of reference to
the other thread or the previous patch, I'm assuming you found and
solved the problem independently and I'd like to add a test case.

Thanks.

-- 
Mel Gorman
SUSE Labs
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ