linux-kernel - Re: [RFC v2 PATCH 0/8] mm: mirrored memory support for page buddy allocations

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:	Tue, 30 Jun 2015 12:46:54 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Xishi Qiu <qiuxishi@...wei.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Xiexiuqi <xiexiuqi@...wei.com>, leon@...n.nu,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Linux MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 PATCH 0/8] mm: mirrored memory support for page buddy
 allocations


* Mel Gorman <mgorman@...e.de> wrote:

> [...]
> 
> Basically, overall I feel this series is the wrong approach but not knowing who 
> the users are making is much harder to judge. I strongly suspect that if 
> mirrored memory is to be properly used then it needs to be available before the 
> page allocator is even active. Once active, there needs to be controlled access 
> for allocation requests that are really critical to mirror and not just all 
> kernel allocations. None of that would use a MIGRATE_TYPE approach. It would be 
> alterations to the bootmem allocator and access to an explicit reserve that is 
> not accounted for as "free memory" and accessed via an explicit GFP flag.

So I think the main goal is to avoid kernel crashes when a #MC memory fault 
arrives on a piece of memory that is owned by the kernel.

In that sense 'protecting' all kernel allocations is natural: we don't know how to 
recover from faults that affect kernel memory.

We do know how to recover from faults that affect user-space memory alone.

So if a mechanism is in place that prioritizes 3 groups of allocators:

  - non-recoverable memory (kernel allocations mostly)

  - high priority user memory (critical apps that must never fail)

  - recoverable user memory (non-dirty caches that can simply be dropped,
    non-critical apps, etc.)

then we can make use of this hardware feature. I suspect this series tries to move 
in that direction.

Thanks,

	Ingo
--
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/