All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oscar Salvador <osalvador@suse.de>, Linux MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 2/3] mm/sparsemem: get physical address to page struct instead of virtual address to pfn
Date: Fri, 7 Feb 2020 11:13:37 +0000	[thread overview]
Message-ID: <20200207111337.bqahz3ex65ggu2ri@master> (raw)
In-Reply-To: <20200207033636.GS8965@MiWiFi-R3L-srv>

On Fri, Feb 07, 2020 at 11:36:36AM +0800, Baoquan He wrote:
>On 02/06/20 at 07:21pm, Dan Williams wrote:
>> On Thu, Feb 6, 2020 at 7:10 PM Baoquan He <bhe@redhat.com> wrote:
>> >
>> > Hi Dan,
>> >
>> > On 02/06/20 at 06:19pm, Dan Williams wrote:
>> > > On Thu, Feb 6, 2020 at 3:17 PM Wei Yang <richardw.yang@linux.intel.com> wrote:
>> > > > diff --git a/mm/sparse.c b/mm/sparse.c
>> > > > index b5da121bdd6e..56816f653588 100644
>> > > > --- a/mm/sparse.c
>> > > > +++ b/mm/sparse.c
>> > > > @@ -888,7 +888,7 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn,
>> > > >         /* Align memmap to section boundary in the subsection case */
>> > > >         if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) &&
>> > > >                 section_nr_to_pfn(section_nr) != start_pfn)
>> > > > -               memmap = pfn_to_kaddr(section_nr_to_pfn(section_nr));
>> > > > +               memmap = pfn_to_page(section_nr_to_pfn(section_nr));
>> > >
>> > > Yes, this looks obviously correct. This might be tripping up
>> > > makedumpfile. Do you see any practical effects of this bug? The kernel
>> > > mostly avoids ->section_mem_map in the vmemmap case and in the
>> > > !vmemmap case section_nr_to_pfn(section_nr) should always equal
>> > > start_pfn.
>> >
>> > The practical effects is that the memmap for the first unaligned section will be lost
>> > when destroy namespace to hot remove it. Because we encode the ->section_mem_map
>> > into mem_section, and get memmap from the related mem_section to free it in
>> > section_deactivate(). In fact in vmemmap, we don't need to encode the ->section_mem_map
>> > with memmap.
>> 
>> Right, but can you actually trigger that in the SPARSEMEM_VMEMMAP=n case?
>
>I think no, the lost memmap should only happen in vmemmap case.
>
>> 
>> > By the way, sub-section support is only valid in vmemmap case, right?
>> 
>> Yes.
>> 
>> > Seems yes from code, but I don't find any document to prove it.
>> 
>> check_pfn_span() enforces this requirement.

I saw this function, but those combination of vmemmap and !vmemmap make my
brain not work properly.

>
>Thanks for your confirmation. Do you mind if I add some document
>sentences somewhere make clear this?

Thanks, hope this would help the future audience.


-- 
Wei Yang
Help you, Help me

  parent reply	other threads:[~2020-02-07 11:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 23:16 [PATCH 0/3] Fixes "mm/sparsemem: support sub-section hotplug" Wei Yang
2020-02-06 23:16 ` [PATCH 1/3] mm/sparsemem: adjust memmap only for SPARSEMEM_VMEMMAP Wei Yang
2020-02-07  2:00   ` Dan Williams
2020-02-07  2:00     ` Dan Williams
2020-02-07 11:06     ` Wei Yang
2020-02-06 23:16 ` [PATCH 2/3] mm/sparsemem: get physical address to page struct instead of virtual address to pfn Wei Yang
2020-02-07  2:19   ` Dan Williams
2020-02-07  2:19     ` Dan Williams
2020-02-07  3:10     ` Baoquan He
2020-02-07  3:21       ` Dan Williams
2020-02-07  3:21         ` Dan Williams
2020-02-07  3:36         ` Baoquan He
2020-02-07  4:05           ` Dan Williams
2020-02-07  4:05             ` Dan Williams
2020-02-07 11:13           ` Wei Yang [this message]
2020-02-07 12:14         ` Wei Yang
2020-02-07 16:44           ` Dan Williams
2020-02-07 16:44             ` Dan Williams
2020-02-07 10:51     ` Wei Yang
2020-02-07 11:26     ` Wei Yang
2020-02-09 13:50       ` Baoquan He
2020-02-09 14:14         ` David Hildenbrand
2020-02-10  0:36           ` Wei Yang
2020-02-07  4:11   ` Baoquan He
2020-02-07 10:53     ` Wei Yang
2020-02-06 23:16 ` [PATCH 3/3] mm/sparsemem: avoid memmap overwrite for non-SPARSEMEM_VMEMMAP Wei Yang
2020-02-07  2:06   ` Dan Williams
2020-02-07  2:06     ` Dan Williams
2020-02-07  3:50     ` Baoquan He
2020-02-07 11:02     ` Wei Yang

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=20200207111337.bqahz3ex65ggu2ri@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=richardw.yang@linux.intel.com \
    /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.