linux-kernel - Re: Dirty pages underflow on 3.14.23

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: <20150106150250.GA26895@phnom.home.cmpxchg.org>
Date:	Tue, 6 Jan 2015 10:02:50 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Vlastimil Babka <vbabka@...e.cz>, Leon Romanovsky <leon@...n.nu>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: Dirty pages underflow on 3.14.23

On Mon, Jan 05, 2015 at 06:05:59PM -0500, Mikulas Patocka wrote:
> Hi
> 
> I would like to report a memory management bug where the dirty pages count 
> underflowed.
> 
> It happened after some time that the Dirty pages count underflowed, as can 
> be seen in /proc/meminfo. The underflow condition was persistent, 
> /proc/meminfo was showing the big value even when the system was 
> completely idle. The counter never returned to zero.
> 
> The system didn't crash, but it became very slow - because of the big 
> value in the "Dirty" field, lazy writing was not working anymore, any 
> process that created a dirty page triggered immediate writeback, which 
> slowed down the system very much. The only fix was to reboot the machine.
> 
> The kernel version where this happened is 3.14.23. The kernel is compiled 
> without SMP and with peemption. The system is single-core 32-bit x86.
> 
> The bug probably happened during git pull or apt-get update, though one 
> can't be sure that these commands caused it.
> 
> I see that 3.14.24 containes some fix for underflow (commit 
> 6619741f17f541113a02c30f22a9ca22e32c9546, upstream commit 
> abe5f972912d086c080be4bde67750630b6fb38b), but it doesn't seem that that 
> commit fixes this condition. If you have a commit that could fix this, say 
> it.

That's an unrelated counter, but there is a known dirty underflow
problem that was addressed in 87a7e00b206a ("mm: protect
set_page_dirty() from ongoing truncation").  It should make it into
the stable kernels in the near future.  Can you reproduce this issue?

Thanks,
Johannes
--
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/