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:	Wed, 21 Oct 2015 16:33:38 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, rientjes@...gle.com,
	oleg@...hat.com, kwalker@...hat.com, akpm@...ux-foundation.org,
	hannes@...xchg.org, vdavydov@...allels.com, skozina@...hat.com,
	mgorman@...e.de, riel@...hat.com
Subject: Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable()
 checks

On Wed 21-10-15 09:22:40, Christoph Lameter wrote:
> On Wed, 21 Oct 2015, Tetsuo Handa wrote:
> 
> > However, if a workqueue which is processed before vmstat_update
> > workqueue is processed got stuck inside memory allocation request,
> > values in vm_stat_diff[] cannot be merged into vm_stat[]. As a result,
> > zone_reclaimable() continues using outdated vm_stat[] values and the
> > task which is doing direct reclaim path thinks that there are reclaimable
> > pages and therefore continues looping. The consequence is a silent
> > livelock (hang up without any kernel messages) because the OOM killer
> > will not be invoked.
> 
> The diffs will be merged if they reach a certain threshold regardless. You
> can decrease that threshhold. See calculate_pressure_threshhold().

The thing is that they will not reach the threshold. The LRUs in this
particular case are empty so there is nothing scanned so
NR_PAGES_SCANNED doesn't increase.

> Why is the merging not occurring if a process gets stuck? Workrequests are
> not blocked by a process being stuck doing memory allocation or reclaim.

Because all the WQ workers are stuck somewhere, maybe in the memory
allocation which cannot make any progress and the vmstat update work is
queued behind them.

At least this is my current understanding.
-- 
Michal Hocko
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