From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161085AbdD0DG2 (ORCPT ); Wed, 26 Apr 2017 23:06:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161063AbdD0DGU (ORCPT ); Wed, 26 Apr 2017 23:06:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7648085542 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dyoung@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7648085542 Date: Thu, 27 Apr 2017 11:06:07 +0800 From: Dave Young To: xlpang@redhat.com Cc: Juergen Gross , linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org, Baoquan He , kexec@lists.infradead.org, Petr Tesarik , linux-kernel@vger.kernel.org, Eric Biederman , Hari Bathini , akpm@linux-foundation.org, Michael Holzheu Subject: Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section Message-ID: <20170427030607.GB10602@dhcp-128-65.nay.redhat.com> References: <1492688374-27903-1-git-send-email-xlpang@redhat.com> <20170426071916.GD5381@dhcp-128-65.nay.redhat.com> <59006DAB.8030908@redhat.com> <59007405.6070107@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59007405.6070107@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 27 Apr 2017 03:06:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [snip] > >>> > >>> static int __init crash_save_vmcoreinfo_init(void) > >>> { > >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >> page assumption? > >> > >> Or just define the VMCOREINFO_BYTES as PAGE_SIZE instead of 4096 > > Yes, I considered this before, but VMCOREINFO_BYTES is also used by VMCOREINFO_NOTE_SIZE > > definition which is exported to sysfs, also some platform has larger page size(64KB), so > > I didn't touch this 4096 value. > > > > I think I should use kmalloc() to allocate both of them, then move this comment to Patch3 > > kimage_crash_copy_vmcoreinfo(). > > But on the other hand, using a separate page for them seems safer compared with > using frequently-used slab, what's your opinion? I feel current page based way is better. For 64k page the vmcore note size will increase it seems fine. Do you have concern in mind? Thanks