From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752601AbcA2DOg (ORCPT ); Thu, 28 Jan 2016 22:14:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32774 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228AbcA2DOf (ORCPT ); Thu, 28 Jan 2016 22:14:35 -0500 Reply-To: xlpang@redhat.com Subject: Re: [PATCH] kexec: unmap reserved pages for each error-return way References: <1453895311-11087-1-git-send-email-dsafonov@virtuozzo.com> <20160127111546.2212f191f5f313b613f6b60b@linux-foundation.org> <56A983F3.5010506@redhat.com> <56A9D927.70402@virtuozzo.com> To: Dmitry Safonov , xlpang@redhat.com Cc: Andrew Morton , linux-s390@vger.kernel.org, heiko.carstens@de.ibm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com, 0x7f454c46@gmail.com, schwidefsky@de.ibm.com, holzheu@linux.vnet.ibm.com, dyoung@redhat.com From: Xunlei Pang Message-ID: <56AAD90F.20201@redhat.com> Date: Fri, 29 Jan 2016 11:14:23 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56A9D927.70402@virtuozzo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/01/28 at 17:02, Dmitry Safonov wrote: > On 01/28/2016 05:58 AM, Xunlei Pang wrote: >> Hi Dmitry, >> >> On 2016/01/28 at 03:15, Andrew Morton wrote: >>> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov wrote: >>> >>>> For allocation of kimage failure or kexec_prepare or load segments >>>> errors there is no need to keep crashkernel memory mapped. >>>> It will affect only s390 as map/unmap hook defined only for it. >>>> As on unmap s390 also changes os_info structure let's check return code >>>> and add info only on success. >>>> >>> This conflicts (both mechanically and somewhat conceptually) with >>> Xunlei Pang's "kexec: Introduce a protection mechanism for the >>> crashkernel reserved memory" and "kexec: provide >>> arch_kexec_protect(unprotect)_crashkres()". >>> >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory.patch >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory-v4.patch >>> >>> and >>> >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres.patch >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres-v4.patch >>> >>> so can we please sort all that out? >> >> Ah, I've checked git-log history, they are almost the same idea, can crash_unmap/map_reserved_pages() >> be re-implemented using the new arch_kexec_unprotect/protect_crashkres() on S390? > Sorry, didn't fetched akpm before sending. > Yes, sounds like really right thing to do to have one united arch-helper. Yeah, as Michael said, "memblock_remove(crash_base, crash_size)" creates a big hole in the kernel pgtable. In order to have one united arch-helper, I guess we can forbid this to let the pgtable setup for crash memory, then we can easily move the logic of crash_map_reserved_pages() to arch_kexec_unprotect_crashkres(), and move crash_unmap_reserved_pages() to arch_kexec_protect_crashkres(). After that crash_map_reserved_pages() called in crash_shrink_memory() can be safely removed as well. Regards, Xunlei >> >> Regards, >> Xunlei >> >>> _______________________________________________ >>> kexec mailing list >>> kexec@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/kexec >> > > > -- > Regards, > Dmitry Safonov From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aOzWS-0006kP-82 for kexec@lists.infradead.org; Fri, 29 Jan 2016 03:14:57 +0000 Subject: Re: [PATCH] kexec: unmap reserved pages for each error-return way References: <1453895311-11087-1-git-send-email-dsafonov@virtuozzo.com> <20160127111546.2212f191f5f313b613f6b60b@linux-foundation.org> <56A983F3.5010506@redhat.com> <56A9D927.70402@virtuozzo.com> From: Xunlei Pang Message-ID: <56AAD90F.20201@redhat.com> Date: Fri, 29 Jan 2016 11:14:23 +0800 MIME-Version: 1.0 In-Reply-To: <56A9D927.70402@virtuozzo.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: xlpang@redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Dmitry Safonov , xlpang@redhat.com Cc: linux-s390@vger.kernel.org, kexec@lists.infradead.org, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, ebiederm@xmission.com, 0x7f454c46@gmail.com, schwidefsky@de.ibm.com, Andrew Morton , holzheu@linux.vnet.ibm.com, dyoung@redhat.com On 2016/01/28 at 17:02, Dmitry Safonov wrote: > On 01/28/2016 05:58 AM, Xunlei Pang wrote: >> Hi Dmitry, >> >> On 2016/01/28 at 03:15, Andrew Morton wrote: >>> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov wrote: >>> >>>> For allocation of kimage failure or kexec_prepare or load segments >>>> errors there is no need to keep crashkernel memory mapped. >>>> It will affect only s390 as map/unmap hook defined only for it. >>>> As on unmap s390 also changes os_info structure let's check return code >>>> and add info only on success. >>>> >>> This conflicts (both mechanically and somewhat conceptually) with >>> Xunlei Pang's "kexec: Introduce a protection mechanism for the >>> crashkernel reserved memory" and "kexec: provide >>> arch_kexec_protect(unprotect)_crashkres()". >>> >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory.patch >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-introduce-a-protection-mechanism-for-the-crashkernel-reserved-memory-v4.patch >>> >>> and >>> >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres.patch >>> http://ozlabs.org/~akpm/mmots/broken-out/kexec-provide-arch_kexec_protectunprotect_crashkres-v4.patch >>> >>> so can we please sort all that out? >> >> Ah, I've checked git-log history, they are almost the same idea, can crash_unmap/map_reserved_pages() >> be re-implemented using the new arch_kexec_unprotect/protect_crashkres() on S390? > Sorry, didn't fetched akpm before sending. > Yes, sounds like really right thing to do to have one united arch-helper. Yeah, as Michael said, "memblock_remove(crash_base, crash_size)" creates a big hole in the kernel pgtable. In order to have one united arch-helper, I guess we can forbid this to let the pgtable setup for crash memory, then we can easily move the logic of crash_map_reserved_pages() to arch_kexec_unprotect_crashkres(), and move crash_unmap_reserved_pages() to arch_kexec_protect_crashkres(). After that crash_map_reserved_pages() called in crash_shrink_memory() can be safely removed as well. Regards, Xunlei >> >> Regards, >> Xunlei >> >>> _______________________________________________ >>> kexec mailing list >>> kexec@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/kexec >> > > > -- > Regards, > Dmitry Safonov _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec