linux-kernel - Re: swapoff() runs forever

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: <4F833BF5.4040001@nod.at>
Date:	Mon, 09 Apr 2012 21:43:49 +0200
From:	Richard Weinberger <richard@....at>
To:	Hugh Dickins <hughd@...gle.com>
CC:	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"paul.gortmaker@...driver.com" <paul.gortmaker@...driver.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: swapoff() runs forever

Am 09.04.2012 20:40, schrieb Hugh Dickins:
> On Mon, 9 Apr 2012, Richard Weinberger wrote:
>> Am 09.04.2012 07:35, schrieb Konstantin Khlebnikov:
>>> Richard Weinberger wrote:
>>>> Hi!
>>>>
>>>> I'm observing a strange issue (at least on UML) on recent Linux kernels.
>>>> If swap is being used the swapoff() system call never terminates.
>>>> To be precise "while ((i = find_next_to_unuse(si, i)) != 0)" in try_to_unuse()
>>>> never terminates.
>>>>
>>>> The affected machine has 256MiB ram and 256MiB swap.
>>>> If an application uses more than 256MiB memory swap is being used.
>>>> But after the application terminates the free command still reports that a few
>>>> MiB are on my swap device and swappoff never terminates.
>>>
>>> After last tmpfs changes swapoff can take minutes.
>>> Or this time it really never terminates?
>>
>> I've never waited forever. ;-)
>
> Your lack of dedication is disappointing.
>
>> Once I've waited for>30 minutes.
>>
>> I don't think that it's related to tmpfs because it happens
>> also while shutting down the system after all filesystems have been unmounted.
>
> Like you I'd assume that it is really was going to be forever,
> rather than swapoff just being characteristically slow:
> a few MiB left on swap shouldn't take long to get off.
>
> I've not seen any such issue in recent months (or years), but
> I've not been using UML either.  The most likely cause that springs
> to mind would be corruption of the vmalloc'ed swap map: that would
> be very likely to cause such a hang.

Okay, I'll dig into this.

> You say "recent Linux kernels": I wonder what "recent" means.
> Is this something you can reproduce quickly and reliably enough
> to do a bisection upon?
>

It happens quite reliably on 3.2 and 3.3.
On 3.1 and 3.0 sometimes.
I've already wasted half a day with bisecting it.

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