linux-kernel - Re: [RFC PATCH 0/4 V2] introduce: livedump

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] [day] [month] [year] [list]

Message-ID: <4FCDD65B.6090402@hitachi.com>
Date:	Tue, 05 Jun 2012 18:50:19 +0900
From:	YOSHIDA Masanori <masanori.yoshida.tv@...achi.com>
To:	Vivek Goyal <vgoyal@...hat.com>, "H. Peter Anvin" <hpa@...or.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Andy Lutomirski <luto@....edu>,
	Ingo Molnar <mingo@...e.hu>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Kees Cook <keescook@...omium.org>,
	Kevin Hilman <khilman@...com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Prarit Bhargava <prarit@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tejun Heo <tj@...nel.org>,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC PATCH 0/4 V2] introduce: livedump

Hi, Vivek and Peter

Thank you for your replies.

Yes, I agree that it is terrible to consume a half of memory only for
this purpose.

I think buffer size can be reduced by dumping memory to disk
on-the-fly with buffer of limited size.
However, this means that page fault(PF) handling may sleep if the
buffer is temporarily full.
It is never acceptable when PF happens in preempt_disable()ed path,
but I think size of pages updated in the path is not much.

To reduce buffer size, we can introduce two types of buffers as below;
(1)Buffer dedicated for non-preemptible path
(2)Buffer for the rest

If the first buffer is full, tracking updated pages partially fails.
To avoid this, users need to allocate enough memory for this buffer.

We don't need to care about the second buffer being full,
because PF handling can wait for space by sleeping.

Regards,
Masanori

Yokohama Research Laboratory,
Hitachi, Ltd.


On 2012/06/05 6:09, Vivek Goyal wrote:
> On Fri, May 25, 2012 at 06:12:07PM +0900, YOSHIDA Masanori wrote:
>
> [..]
>> (4) It allocates about 50% of physical RAM to store dumped pages. Currently
>>      Live Dump saves all dumped data on memory once, and after that a user
>>      becomes able to use the dumped data. Live Dump itself has no feature to
>>      save dumped data onto a disk or any other storage device.
>
> People complain when kdump reserves 128M of memory when system crashes.
> I am skeptical that reserving 50% of memory for livedumps is going to fly.
>
> Thanks
> Vivek

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