From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Vj1WZ-0004lM-59 for kexec@lists.infradead.org; Wed, 20 Nov 2013 06:44:32 +0000 Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 9B2063EE0C1 for ; Wed, 20 Nov 2013 15:44:05 +0900 (JST) Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 87D0045DE4C for ; Wed, 20 Nov 2013 15:44:05 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.nic.fujitsu.com [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 647AC45DE50 for ; Wed, 20 Nov 2013 15:44:05 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 576961DB803A for ; Wed, 20 Nov 2013 15:44:05 +0900 (JST) Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.240.81.134]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id E952B1DB803E for ; Wed, 20 Nov 2013 15:44:04 +0900 (JST) Message-ID: <528C5A1C.3040103@jp.fujitsu.com> Date: Wed, 20 Nov 2013 15:43:40 +0900 From: HATAYAMA Daisuke MIME-Version: 1.0 Subject: Re: /proc/vmcore mmap() failure issue References: <20131113204130.GD7613@redhat.com> <5284A689.70903@jp.fujitsu.com> <20131114151359.GA3913@redhat.com> <5285EC60.1060906@jp.fujitsu.com> <20131115142617.GC6637@redhat.com> <0910DD04CBD6DE4193FCF86B9C00BE971BF592@BPXM01GP.gisp.nec.co.jp> <528B3585.5080606@jp.fujitsu.com> <0910DD04CBD6DE4193FCF86B9C00BE971C3845@BPXM01GP.gisp.nec.co.jp> In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971C3845@BPXM01GP.gisp.nec.co.jp> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Atsushi Kumagai Cc: "bhe@redhat.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "vgoyal@redhat.com" , "ebiederm@xmission.com" , "dyoung@redhat.com" , "chaowang@redhat.com" (2013/11/20 14:27), Atsushi Kumagai wrote: > On 2013/11/19 18:56:21, kexec wrote: >> (2013/11/18 9:51), Atsushi Kumagai wrote: >>> (2013/11/15 23:26), Vivek Goyal wrote: >>>> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote: >>>> >>>> [..] >>>>>> Given the fact that hpa does not like fixing it in kernel. We are >>>>>> left with option of fixing it in following places. >>>>>> >>>>>> - Drop partial pages in kexec-tools >>>>>> - Drop partial pages in makeudmpfile. >>>>>> - Read partial pages using read() interface in makedumpfile >>>>>> - Modify /proc/vmcore to copy partial pages in second kernel's memory. >>>>>> >>>>>> It is not clear to me that partial pages are really useful. So I >>>>>> want to avoid modifying /proc/vmcore to deal with partial pages and >>>>>> increase complexity. >>>>>> >>>>>> So fixing makedumpfile (either option2 or option 3) seems least >>>>>> risky to me. In fact I would say let us keep it simple and truncate >>>>>> partial pages in makedumpfile to keep it simple. And look at option >>>>>> 3 once we have a strong use case for partial pages. >>>>>> >>>>>> What do you think? >>>>>> >>>>> >>>>> As you say, it's not clear that partial pages are really useful, but >>>>> on the other hand, it seems to me not clear that they are really useless. >>>>> I think we should get them as long as we have access to them. >>>>> >>>>> It seems best to me the option 3). Switching between read and mmap >>>>> would be not so complex and also it's by far flexible in >>>>> makedumpfile than in kernel. >>>> >>>> Ok, I am fine with option 3. It is more complicated option but safe >>>> option. >>> >>> It sounds reasonable also to me. >>> >>>> Is there any chance that you could look into fixing this. I have no >>>> experience writing code for makedumpfile. >>> >>> I'll send a patch to fix this soon. >>> >> >> Thanks. >> >> BTW, now the following patch has been applied on top of makedumpfile in kexec-tools package on fedora in order to avoid the issue. >> >> https://lists.fedoraproject.org/pipermail/kexec/2013-November/000254.html >> >> I remember prototype version of mmap patch implemented a kind of --no-mmap option and we could use it to disable mmap() use and use read() instead, I think which is useful when we face this kind of issue. > > How about this fail back structure instead of such an extra option ? > I think this logic is useful and should be merged together in this fix. However, I still think a kind of --no-mmap option is needed. There could happen worse case due to mmap() in the future on some system, of course, I don't know what the system actually is, but at least it must be behaving differently from typical systems... Then, option is more flexible than patching. It would also be useful for debugging use. read() is simpler than mmap(), and read() is basic in the sense that initially makedumpfile didn't use mmap(). There might be a situation where we want to avoid using mmap(); for example, when makedumpfile works badly and it looks like caused by mmap() code in kernel code; Then, we would want to see if makedumpfile works well by disabling mmap(), -- Thanks. HATAYAMA, Daisuke _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751551Ab3KTGoK (ORCPT ); Wed, 20 Nov 2013 01:44:10 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:38152 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756Ab3KTGoG (ORCPT ); Wed, 20 Nov 2013 01:44:06 -0500 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.9 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20120718-2 Message-ID: <528C5A1C.3040103@jp.fujitsu.com> Date: Wed, 20 Nov 2013 15:43:40 +0900 From: HATAYAMA Daisuke User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Atsushi Kumagai CC: "bhe@redhat.com" , "chaowang@redhat.com" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "ebiederm@xmission.com" , "dyoung@redhat.com" , "vgoyal@redhat.com" Subject: Re: /proc/vmcore mmap() failure issue References: <20131113204130.GD7613@redhat.com> <5284A689.70903@jp.fujitsu.com> <20131114151359.GA3913@redhat.com> <5285EC60.1060906@jp.fujitsu.com> <20131115142617.GC6637@redhat.com> <0910DD04CBD6DE4193FCF86B9C00BE971BF592@BPXM01GP.gisp.nec.co.jp> <528B3585.5080606@jp.fujitsu.com> <0910DD04CBD6DE4193FCF86B9C00BE971C3845@BPXM01GP.gisp.nec.co.jp> In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE971C3845@BPXM01GP.gisp.nec.co.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (2013/11/20 14:27), Atsushi Kumagai wrote: > On 2013/11/19 18:56:21, kexec wrote: >> (2013/11/18 9:51), Atsushi Kumagai wrote: >>> (2013/11/15 23:26), Vivek Goyal wrote: >>>> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote: >>>> >>>> [..] >>>>>> Given the fact that hpa does not like fixing it in kernel. We are >>>>>> left with option of fixing it in following places. >>>>>> >>>>>> - Drop partial pages in kexec-tools >>>>>> - Drop partial pages in makeudmpfile. >>>>>> - Read partial pages using read() interface in makedumpfile >>>>>> - Modify /proc/vmcore to copy partial pages in second kernel's memory. >>>>>> >>>>>> It is not clear to me that partial pages are really useful. So I >>>>>> want to avoid modifying /proc/vmcore to deal with partial pages and >>>>>> increase complexity. >>>>>> >>>>>> So fixing makedumpfile (either option2 or option 3) seems least >>>>>> risky to me. In fact I would say let us keep it simple and truncate >>>>>> partial pages in makedumpfile to keep it simple. And look at option >>>>>> 3 once we have a strong use case for partial pages. >>>>>> >>>>>> What do you think? >>>>>> >>>>> >>>>> As you say, it's not clear that partial pages are really useful, but >>>>> on the other hand, it seems to me not clear that they are really useless. >>>>> I think we should get them as long as we have access to them. >>>>> >>>>> It seems best to me the option 3). Switching between read and mmap >>>>> would be not so complex and also it's by far flexible in >>>>> makedumpfile than in kernel. >>>> >>>> Ok, I am fine with option 3. It is more complicated option but safe >>>> option. >>> >>> It sounds reasonable also to me. >>> >>>> Is there any chance that you could look into fixing this. I have no >>>> experience writing code for makedumpfile. >>> >>> I'll send a patch to fix this soon. >>> >> >> Thanks. >> >> BTW, now the following patch has been applied on top of makedumpfile in kexec-tools package on fedora in order to avoid the issue. >> >> https://lists.fedoraproject.org/pipermail/kexec/2013-November/000254.html >> >> I remember prototype version of mmap patch implemented a kind of --no-mmap option and we could use it to disable mmap() use and use read() instead, I think which is useful when we face this kind of issue. > > How about this fail back structure instead of such an extra option ? > I think this logic is useful and should be merged together in this fix. However, I still think a kind of --no-mmap option is needed. There could happen worse case due to mmap() in the future on some system, of course, I don't know what the system actually is, but at least it must be behaving differently from typical systems... Then, option is more flexible than patching. It would also be useful for debugging use. read() is simpler than mmap(), and read() is basic in the sense that initially makedumpfile didn't use mmap(). There might be a situation where we want to avoid using mmap(); for example, when makedumpfile works badly and it looks like caused by mmap() code in kernel code; Then, we would want to see if makedumpfile works well by disabling mmap(), -- Thanks. HATAYAMA, Daisuke