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]

Date:	Mon, 9 Apr 2012 11:40:32 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Richard Weinberger <richard@....at>
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

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.

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?

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