linux-kernel - Re: Raid 0 Swap?

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, 4 Sep 2006 12:46:31 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Michael Tokarev <mjt@....msk.ru>
cc:	Helge Hafting <helge.hafting@...el.hist.no>,
	Marc Perkel <marc@...kel.com>, linux-kernel@...r.kernel.org
Subject: Re: Raid 0 Swap?

>> I thought kernel data weren't swapped at all?

If the swap code was swapped, who would swap it in again?

>Well, it's not that simple.  Kernel uses both swappable and
>non-swappable memory internally.  For some things, it's
>unswappable, for some, it's swappable.  In general, it's
>impossible to say which parts of kernel will break (and
>in wich ways) if swap goes havoc.

In general, everything you type in as C code (.bss, .data, .text) should be 
unswappable. kmalloc()ed areas are resident too, and kmalloc has a 
parameter which defines whether the allocation can/cannot push userspace 
pages into the swap (GFP_ATOMIC/GFP_IO). So if there is some 
kernel-allocation swapped out, it is most likely to be marked as 
'userspace' so that the same algorithms can be used for swapin and -out.

Jan Engelhardt
-- 

-- 
VGER BF report: H 5.48632e-07
-
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/