linux-kernel - Re: [Bisected Regression in 2.6.35] A full tmpfs filesystem causes hibernationto hang

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: <20100820115449.5FF1.A69D9226@jp.fujitsu.com>
Date:	Sun, 22 Aug 2010 20:06:24 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	"M. Vefa Bicakci" <bicave@...eronline.com>
Cc:	kosaki.motohiro@...fujitsu.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Bisected Regression in 2.6.35] A full tmpfs filesystem causes hibernationto hang

> Hello all,
> 
> I am using Debian Sid on a Toshiba Satellite A100 laptop. After testing
> 2.6.35 for a while, I noticed that sometimes my hibernation attempts
> would fail. I should say that I never had such a problem before 2.6.35.
> The hibernation process hangs with 2.6.35 after printing the following:
> 
> === 8< ===
> ...
> Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> PM: Preallocating image memory...
> === >8 ===
> 
> After a short investigation, I found out that this only happens when my
> tmpfs filesystem on /tmp had a lot of data in it. When my tmpfs is empty,
> I have no problems.
> 
> So I wrote a short script which fills up the tmpfs on /tmp and tries to
> hibernate, and I bisected the kernel using this script.
> 
> The end result is that the following commit causes this regression:
> 
> === 8< ===
> commit bb21c7ce18eff8e6e7877ca1d06c6db719376e3c
> Author: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> Date:   Fri Jun 4 14:15:05 2010 -0700
> 
>     vmscan: fix do_try_to_free_pages() return value when priority==0 reclaim failure
> 
>     ...
> === >8 ===
> 
> I have run 2.6.35-rc6, 2.6.35 and 2.6.35.1 with this commit reverted,
> and I am happy to say that I haven't experienced any problems for at
> least 17 days.
> 
> It looks like this change was included with 2.6.35-rc1. I am sorry
> for not testing earlier.
> 
> I am willing to do testing in case anyone would like me to try patches.
> 
> Regards,
> 
> M. Vefa Bicakci

Hmm... 
I've tested hibernation case for a while. but I have no luck. I couldn't
reproduce your issue. Very sorry. Can you please help our debugging? 
If possible, I hope to run following three test.

1. Please let me know your machine & test script

% cat /proc/meminfo
% cat /proc/vmstat
% cat /proc/zoneinfo
% df
% cat your-fills-up-the-tmpfs-script

2. call shrink_all_memory() forcely and show result

% cat /proc/meminfo
% cat /proc/zoneinfo
# echo 1 > /proc/sys/vm/shrink_all_memory
# tail /var/log/messages
% cat /proc/meminfo
% cat /proc/zoneinfo


3. reset zone_reclaim_stat and rerun shrink_all_memory

# echo 1 > /proc/sys/vm/reset_reclaim_stat
% cat /proc/meminfo
% cat /proc/zoneinfo
# echo 1 > /proc/sys/vm/shrink_all_memory
# tail /var/log/messages
% cat /proc/meminfo
% cat /proc/zoneinfo



Download attachment "0001-debug-print-sysctl.patch" of type "application/octet-stream" (2174 bytes)

Download attachment "0003-debug-reset_reclaim_stat.patch" of type "application/octet-stream" (1654 bytes)

Download attachment "0004-debug-zone_info-reclaim_stat.patch" of type "application/octet-stream" (1575 bytes)