linux-kernel - Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore

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: <20130321.153537.03532110.d.hatayama@jp.fujitsu.com>
Date:	Thu, 21 Mar 2013 15:35:37 +0900 (JST)
From:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To:	ebiederm@...ssion.com
Cc:	akpm@...ux-foundation.org, vgoyal@...hat.com, cpw@....com,
	kumagai-atsushi@....nes.nec.co.jp, lisa.mitchell@...com,
	heiko.carstens@...ibm.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, zhangyanfei@...fujitsu.com
Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore

From: "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
Date: Wed, 20 Mar 2013 23:16:20 -0700

> HATAYAMA Daisuke <d.hatayama@...fujitsu.com> writes:
> 
>> From: Andrew Morton <akpm@...ux-foundation.org>
>> Subject: Re: [PATCH v3 00/21] kdump, vmcore: support mmap() on /proc/vmcore
>> Date: Tue, 19 Mar 2013 12:30:05 -0700
>>
>>> On Sat, 16 Mar 2013 13:00:47 +0900 HATAYAMA Daisuke <d.hatayama@...fujitsu.com> wrote:
>>> 
>>>> Currently, read to /proc/vmcore is done by read_oldmem() that uses
>>>> ioremap/iounmap per a single page. For example, if memory is 1GB,
>>>> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
>>>> times. This causes big performance degradation.
>>>> 
>>>> In particular, the current main user of this mmap() is makedumpfile,
>>>> which not only reads memory from /proc/vmcore but also does other
>>>> processing like filtering, compression and IO work. Update of page
>>>> table and the following TLB flush makes such processing much slow;
>>>> though I have yet to make patch for makedumpfile and yet to confirm
>>>> how it's improved.
>>>> 
>>>> To address the issue, this patch implements mmap() on /proc/vmcore to
>>>> improve read performance. My simple benchmark shows the improvement
>>>> from 200 [MiB/sec] to over 50.0 [GiB/sec].
>>> 
>>> There are quite a lot of userspace-visible vmcore changes here.  Is it
>>> all fully back-compatible?  Will all known userspace continue to work
>>> OK on newer kernels?
>>> 
>>
>> I designed it to keep backward-compatibility at least for gdb and
>> binutils but not less for makedumpfile since it should follow kernel
>> changes; old makedumpfile cannot use newer kernels, and this is within
>> the range of this review.
> 
> To the extent possible we should different versions of tools to be
> interchanged.  That helps with bug hunting and for people who are in
> resource constrained systems that build old versions of the tools that
> are tiny and fit.
> 
> Given that rounding the per cpu NOTES turns out to be a waste of memory
> I didn't see anything in the patchset that justfies any breakage.

The breakage was caused by the introduction of new NT_VMCORE_PAD to
"VMCOREINFO" name, except for which it worked fine. But it will be
dropped in the next version. It'll be no problem for some time.

The breakage was caused by makedumpfile itself due to the bug that it
had so far seen note type only, not note name. It was possible to
avoid the breakage by choosing another note name but I didn't do
it. This topic will probably arise when some kind of new note types
are needed.

Thanks.
HATAYAMA, Daisuke

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