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: <4F82752A.6020206@openvz.org>
Date:	Mon, 09 Apr 2012 09:35:38 +0400
From:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
To:	Richard Weinberger <richard@....at>
CC:	"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

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?

>
> Here some numbers:
> root@...ux:~# free
>               total       used       free     shared    buffers     cached
> Mem:        255472      13520     241952          0        312       7080
> -/+ buffers/cache:       6128     249344
> Swap:       262140      17104     245036
> root@...ux:~# cat /proc/meminfo
> MemTotal:         255472 kB
> MemFree:          241952 kB
> Buffers:             312 kB
> Cached:             7080 kB
> SwapCached:            0 kB
> Active:             3596 kB
> Inactive:           6076 kB
> Active(anon):       1512 kB
> Inactive(anon):      848 kB
> Active(file):       2084 kB
> Inactive(file):     5228 kB
> Unevictable:           0 kB
> Mlocked:               0 kB
> SwapTotal:        262140 kB
> SwapFree:         245036 kB
> Dirty:                 0 kB
> Writeback:             0 kB
> AnonPages:          2296 kB
> Mapped:             1824 kB
> Shmem:                80 kB
> Slab:               2452 kB
> SReclaimable:       1116 kB
> SUnreclaim:         1336 kB
> KernelStack:         192 kB
> PageTables:          556 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:      389876 kB
> Committed_AS:     238412 kB
> VmallocTotal:    3788784 kB
> VmallocUsed:          68 kB
> VmallocChunk:    3788716 kB
>
> What could cause this issue?
> I'm not sure whether this is UML specific or not.
> Maybe only UML is able to trigger the issue...
>
> 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/