From: ebiederm@xmission.com (Eric W. Biederman) To: Hari Bathini <hbathini@linux.ibm.com> Cc: Joonsoo Kim <js1304@gmail.com>, kernel-team@lge.com, Michal Hocko <mhocko@suse.com>, Minchan Kim <minchan@kernel.org>, "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>, Rik van Riel <riel@surriel.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, LKML <linux-kernel@vger.kernel.org>, Christian Koenig <christian.koenig@amd.com>, Christoph Hellwig <hch@infradead.org>, Linux Memory Management List <linux-mm@kvack.org>, Huang Rui <ray.huang@amd.com>, Kexec Mailing List <kexec@lists.infradead.org>, Pavel Machek <pavel@ucw.cz>, Johannes Weiner <hannes@cmpxchg.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Laura Abbott <labbott@redhat.com>, Mel Gorman <mgorman@techsingularity.net>, Roman Gushchin <guro@fb.com>, Vlastimil Babka <vbabka@suse.cz> Subject: Re: [RFC][PATCH] kexec: Teach indirect pages how to live in high memory Date: Tue, 05 May 2020 13:39:16 -0500 [thread overview] Message-ID: <87sggekyzv.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <54a53bfe-6929-2790-9b1d-943e9f47cd62@linux.ibm.com> (Hari Bathini's message of "Tue, 5 May 2020 23:14:32 +0530") Hari Bathini <hbathini@linux.ibm.com> writes: > On 05/05/20 3:29 am, Eric W. Biederman wrote: >> >> Recently a patch was proposed to kimage_alloc_page to slightly alter >> the logic of how pages allocated with incompatible flags were >> detected. The logic was being altered because the semantics of the >> page alloctor were changing yet again. >> >> Looking at that case I realized that there is no reason for it to even >> exist. Either the indirect page allocations and the source page >> allocations could be separated out, or I could do as I am doing now >> and simply teach the indirect pages to live in high memory. >> >> This patch replaced pointers of type kimage_entry_t * with a new type >> kimage_entry_pos_t. This new type holds the physical address of the >> indirect page and the offset within that page of the next indirect >> entry to write. A special constant KIMAGE_ENTRY_POS_INVALID is added >> that kimage_image_pos_t variables that don't currently have a valid >> may be set to. >> >> Two new functions kimage_read_entry and kimage_write_entry have been >> provided to write entries in way that works if they live in high >> memory. >> >> The now unnecessary checks to see if a destination entry is non-zero >> and to increment it if so have been removed. For safety new indrect >> pages are now cleared so we have a guarantee everything that has not >> been used yet is zero. Along with this writing an extra trailing 0 >> entry has been removed, as it is known all trailing entries are now 0. >> >> With highmem support implemented for indirect pages >> kimage_image_alloc_page has been updated to always allocate >> GFP_HIGHUSER pages, and handling of pages with different >> gfp flags has been removed. >> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > Eric, the patch failed with data access exception on ppc64. Using the below patch on top > got me going... Doh! Somehow I thought I had put that logic or something equivalent into kimage_write_entry and it appears I did not. I will see if I can respin the patch. Thank you very much for testing. Eric > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 45862fd..bef52f1 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -570,7 +570,12 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry) > return -ENOMEM; > > ind_addr = page_to_boot_pfn(page) << PAGE_SHIFT; > - kimage_write_entry(image->entry_pos, ind_addr | IND_INDIRECTION); > + > + /* If it is the first entry, handle it here */ > + if (!image->head) > + image->head = ind_addr | IND_INDIRECTION; > + else > + kimage_write_entry(image->entry_pos, ind_addr | IND_INDIRECTION); > > clear_highpage(page); > > @@ -623,7 +628,11 @@ int __weak machine_kexec_post_load(struct kimage *image) > > void kimage_terminate(struct kimage *image) > { > - kimage_write_entry(image->entry_pos, IND_DONE); > + /* This could be the only entry in case of kdump */ > + if (!image->head) > + image->head = IND_DONE; > + else > + kimage_write_entry(image->entry_pos, IND_DONE); > } > > #define for_each_kimage_entry(image, pos, entry) \ > > > Thanks > Hari
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: Hari Bathini <hbathini@linux.ibm.com> Cc: Michal Hocko <mhocko@suse.com>, Andrew Morton <akpm@linux-foundation.org>, Joonsoo Kim <js1304@gmail.com>, Rik van Riel <riel@surriel.com>, "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>, Minchan Kim <minchan@kernel.org>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, LKML <linux-kernel@vger.kernel.org>, Roman Gushchin <guro@fb.com>, Christoph Hellwig <hch@infradead.org>, kernel-team@lge.com, Huang Rui <ray.huang@amd.com>, Johannes Weiner <hannes@cmpxchg.org>, Linux Memory Management List <linux-mm@kvack.org>, Pavel Machek <pavel@ucw.cz>, Kexec Mailing List <kexec@lists.infradead.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Laura Abbott <labbott@redhat.com>, Mel Gorman <mgorman@techsingularity.net>, Christian Koenig <christian.koenig@amd.com>, Vlastimil Babka <vbabka@suse.cz> Subject: Re: [RFC][PATCH] kexec: Teach indirect pages how to live in high memory Date: Tue, 05 May 2020 13:39:16 -0500 [thread overview] Message-ID: <87sggekyzv.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <54a53bfe-6929-2790-9b1d-943e9f47cd62@linux.ibm.com> (Hari Bathini's message of "Tue, 5 May 2020 23:14:32 +0530") Hari Bathini <hbathini@linux.ibm.com> writes: > On 05/05/20 3:29 am, Eric W. Biederman wrote: >> >> Recently a patch was proposed to kimage_alloc_page to slightly alter >> the logic of how pages allocated with incompatible flags were >> detected. The logic was being altered because the semantics of the >> page alloctor were changing yet again. >> >> Looking at that case I realized that there is no reason for it to even >> exist. Either the indirect page allocations and the source page >> allocations could be separated out, or I could do as I am doing now >> and simply teach the indirect pages to live in high memory. >> >> This patch replaced pointers of type kimage_entry_t * with a new type >> kimage_entry_pos_t. This new type holds the physical address of the >> indirect page and the offset within that page of the next indirect >> entry to write. A special constant KIMAGE_ENTRY_POS_INVALID is added >> that kimage_image_pos_t variables that don't currently have a valid >> may be set to. >> >> Two new functions kimage_read_entry and kimage_write_entry have been >> provided to write entries in way that works if they live in high >> memory. >> >> The now unnecessary checks to see if a destination entry is non-zero >> and to increment it if so have been removed. For safety new indrect >> pages are now cleared so we have a guarantee everything that has not >> been used yet is zero. Along with this writing an extra trailing 0 >> entry has been removed, as it is known all trailing entries are now 0. >> >> With highmem support implemented for indirect pages >> kimage_image_alloc_page has been updated to always allocate >> GFP_HIGHUSER pages, and handling of pages with different >> gfp flags has been removed. >> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > Eric, the patch failed with data access exception on ppc64. Using the below patch on top > got me going... Doh! Somehow I thought I had put that logic or something equivalent into kimage_write_entry and it appears I did not. I will see if I can respin the patch. Thank you very much for testing. Eric > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 45862fd..bef52f1 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -570,7 +570,12 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry) > return -ENOMEM; > > ind_addr = page_to_boot_pfn(page) << PAGE_SHIFT; > - kimage_write_entry(image->entry_pos, ind_addr | IND_INDIRECTION); > + > + /* If it is the first entry, handle it here */ > + if (!image->head) > + image->head = ind_addr | IND_INDIRECTION; > + else > + kimage_write_entry(image->entry_pos, ind_addr | IND_INDIRECTION); > > clear_highpage(page); > > @@ -623,7 +628,11 @@ int __weak machine_kexec_post_load(struct kimage *image) > > void kimage_terminate(struct kimage *image) > { > - kimage_write_entry(image->entry_pos, IND_DONE); > + /* This could be the only entry in case of kdump */ > + if (!image->head) > + image->head = IND_DONE; > + else > + kimage_write_entry(image->entry_pos, IND_DONE); > } > > #define for_each_kimage_entry(image, pos, entry) \ > > > Thanks > Hari _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-05-05 18:43 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-29 3:26 [PATCH v2 00/10] change the implementation of the PageHighMem() js1304 2020-04-29 3:26 ` [PATCH v2 01/10] mm/page-flags: introduce PageHighMemZone() js1304 2020-04-29 3:26 ` [PATCH v2 02/10] drm/ttm: separate PageHighMem() and PageHighMemZone() use case js1304 2020-04-29 3:26 ` [PATCH v2 03/10] kexec: " js1304 2020-05-01 14:03 ` Eric W. Biederman 2020-05-01 14:03 ` Eric W. Biederman 2020-05-04 3:10 ` Joonsoo Kim 2020-05-04 3:10 ` Joonsoo Kim 2020-05-04 14:03 ` Eric W. Biederman 2020-05-04 14:03 ` Eric W. Biederman 2020-05-04 14:03 ` Eric W. Biederman 2020-05-04 21:59 ` [RFC][PATCH] kexec: Teach indirect pages how to live in high memory Eric W. Biederman 2020-05-04 21:59 ` Eric W. Biederman 2020-05-04 21:59 ` Eric W. Biederman 2020-05-05 17:44 ` Hari Bathini 2020-05-05 17:44 ` Hari Bathini 2020-05-05 18:39 ` Eric W. Biederman [this message] 2020-05-05 18:39 ` Eric W. Biederman 2020-05-05 18:39 ` Eric W. Biederman 2020-10-09 1:35 ` Joonsoo Kim 2020-10-09 1:35 ` Joonsoo Kim 2020-05-06 5:23 ` [PATCH v2 03/10] kexec: separate PageHighMem() and PageHighMemZone() use case Joonsoo Kim 2020-05-06 5:23 ` Joonsoo Kim 2020-04-29 3:26 ` [PATCH v2 04/10] power: " js1304 2020-05-01 12:22 ` Christoph Hellwig 2020-05-04 3:01 ` Joonsoo Kim 2020-05-04 3:01 ` Joonsoo Kim 2020-04-29 3:26 ` [PATCH v2 05/10] mm/gup: " js1304 2020-05-01 12:24 ` Christoph Hellwig 2020-05-04 3:02 ` Joonsoo Kim 2020-05-04 3:02 ` Joonsoo Kim 2020-04-29 3:26 ` [PATCH v2 06/10] mm/hugetlb: " js1304 2020-05-01 12:26 ` Christoph Hellwig 2020-05-04 3:03 ` Joonsoo Kim 2020-05-04 3:03 ` Joonsoo Kim 2020-04-29 3:26 ` [PATCH v2 07/10] mm: " js1304 2020-05-01 12:30 ` Christoph Hellwig 2020-05-04 3:08 ` Joonsoo Kim 2020-05-04 3:08 ` Joonsoo Kim 2020-04-29 3:26 ` [PATCH v2 08/10] mm/page_alloc: correct the use of is_highmem_idx() js1304 2020-04-29 3:26 ` [PATCH v2 09/10] mm/migrate: replace PageHighMem() with open-code js1304 2020-04-29 3:26 ` [PATCH v2 10/10] mm/page-flags: change the implementation of the PageHighMem() js1304 2020-04-30 1:47 ` [PATCH v2 00/10] " Andrew Morton 2020-05-01 10:52 ` Joonsoo Kim 2020-05-01 10:52 ` Joonsoo Kim 2020-05-01 10:55 ` Christoph Hellwig 2020-05-01 12:15 ` Joonsoo Kim 2020-05-01 12:15 ` Joonsoo Kim 2020-05-01 12:34 ` Christoph Hellwig 2020-05-04 3:09 ` Joonsoo Kim 2020-05-04 3:09 ` Joonsoo Kim
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87sggekyzv.fsf@x220.int.ebiederm.org \ --to=ebiederm@xmission.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.ibm.com \ --cc=christian.koenig@amd.com \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=hbathini@linux.ibm.com \ --cc=hch@infradead.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=js1304@gmail.com \ --cc=kernel-team@lge.com \ --cc=kexec@lists.infradead.org \ --cc=labbott@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=minchan@kernel.org \ --cc=pavel@ucw.cz \ --cc=ray.huang@amd.com \ --cc=riel@surriel.com \ --cc=rjw@rjwysocki.net \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.