All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.