From: Andrew Morton <akpm@linux-foundation.org> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, Baoquan He <bhe@redhat.com>, Sachin Sant <sachinp@linux.vnet.ibm.com>, Pankaj Gupta <pankaj.gupta.linux@gmail.com>, David Hildenbrand <david@redhat.com>, Michal Hocko <mhocko@suse.com>, Wei Yang <richardw.yang@linux.intel.com>, Oscar Salvador <osalvador@suse.de>, Mike Rapoport <rppt@linux.ibm.com> Subject: Re: [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check Date: Wed, 25 Mar 2020 17:38:17 -0700 [thread overview] Message-ID: <20200325173817.a63f20dd0ec618e063569e4a@linux-foundation.org> (raw) In-Reply-To: <20200325031914.107660-1-aneesh.kumar@linux.ibm.com> On Wed, 25 Mar 2020 08:49:14 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > Fixes the below crash (cc's added) > BUG: Kernel NULL pointer dereference on read at 0x00000000 > Faulting instruction address: 0xc000000000c3447c > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1 > ... > NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0 > LR [c000000000088354] vmemmap_free+0x144/0x320 > Call Trace: > section_deactivate+0x220/0x240 > __remove_pages+0x118/0x170 > arch_remove_memory+0x3c/0x150 > memunmap_pages+0x1cc/0x2f0 > devm_action_release+0x30/0x50 > release_nodes+0x2f8/0x3e0 > device_release_driver_internal+0x168/0x270 > unbind_store+0x130/0x170 > drv_attr_store+0x44/0x60 > sysfs_kf_write+0x68/0x80 > kernfs_fop_write+0x100/0x290 > __vfs_write+0x3c/0x70 > vfs_write+0xcc/0x240 > ksys_write+0x7c/0x140 > system_call+0x5c/0x68 > > With commit: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") > section_mem_map is set to NULL after depopulate_section_mem(). This > was done so that pfn_page() can work correctly with kernel config that disables > SPARSEMEM_VMEMMAP. With that config pfn_to_page does > > __section_mem_map_addr(__sec) + __pfn; > where > > static inline struct page *__section_mem_map_addr(struct mem_section *section) > { > unsigned long map = section->section_mem_map; > map &= SECTION_MAP_MASK; > return (struct page *)map; > } > > Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to > check the pfn validity (pfn_valid()). Since section_deactivate release > mem_section->usage if a section is fully deactivated, pfn_valid() check after > a subsection_deactivate cause a kernel crash. > > static inline int pfn_valid(unsigned long pfn) > { > ... > return early_section(ms) || pfn_section_valid(ms, pfn); > } > > where > > static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn) > { > int idx = subsection_map_index(pfn); > > return test_bit(idx, ms->usage->subsection_map); > } > > Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed. > > Fixes: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") d41e2f3bd546 had cc:stable, so I shall add cc:stable to this one as well. > Cc: Baoquan He <bhe@redhat.com> > Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> > --- > mm/sparse.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/sparse.c b/mm/sparse.c > index aadb7298dcef..3012d1f3771a 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -781,6 +781,8 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages, > ms->usage = NULL; > } > memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr); > + /* Mark the section invalid */ > + ms->section_mem_map &= ~SECTION_HAS_MEM_MAP; > } > > if (section_is_early && memmap)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> Cc: Sachin Sant <sachinp@linux.vnet.ibm.com>, Pankaj Gupta <pankaj.gupta.linux@gmail.com>, Michal Hocko <mhocko@suse.com>, Baoquan He <bhe@redhat.com>, David Hildenbrand <david@redhat.com>, linux-kernel@vger.kernel.org, Mike Rapoport <rppt@linux.ibm.com>, linux-mm@kvack.org, Wei Yang <richardw.yang@linux.intel.com>, linuxppc-dev@lists.ozlabs.org, Oscar Salvador <osalvador@suse.de> Subject: Re: [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check Date: Wed, 25 Mar 2020 17:38:17 -0700 [thread overview] Message-ID: <20200325173817.a63f20dd0ec618e063569e4a@linux-foundation.org> (raw) In-Reply-To: <20200325031914.107660-1-aneesh.kumar@linux.ibm.com> On Wed, 25 Mar 2020 08:49:14 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > Fixes the below crash (cc's added) > BUG: Kernel NULL pointer dereference on read at 0x00000000 > Faulting instruction address: 0xc000000000c3447c > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > CPU: 11 PID: 7519 Comm: lt-ndctl Not tainted 5.6.0-rc7-autotest #1 > ... > NIP [c000000000c3447c] vmemmap_populated+0x98/0xc0 > LR [c000000000088354] vmemmap_free+0x144/0x320 > Call Trace: > section_deactivate+0x220/0x240 > __remove_pages+0x118/0x170 > arch_remove_memory+0x3c/0x150 > memunmap_pages+0x1cc/0x2f0 > devm_action_release+0x30/0x50 > release_nodes+0x2f8/0x3e0 > device_release_driver_internal+0x168/0x270 > unbind_store+0x130/0x170 > drv_attr_store+0x44/0x60 > sysfs_kf_write+0x68/0x80 > kernfs_fop_write+0x100/0x290 > __vfs_write+0x3c/0x70 > vfs_write+0xcc/0x240 > ksys_write+0x7c/0x140 > system_call+0x5c/0x68 > > With commit: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") > section_mem_map is set to NULL after depopulate_section_mem(). This > was done so that pfn_page() can work correctly with kernel config that disables > SPARSEMEM_VMEMMAP. With that config pfn_to_page does > > __section_mem_map_addr(__sec) + __pfn; > where > > static inline struct page *__section_mem_map_addr(struct mem_section *section) > { > unsigned long map = section->section_mem_map; > map &= SECTION_MAP_MASK; > return (struct page *)map; > } > > Now with SPASEMEM_VMEMAP enabled, mem_section->usage->subsection_map is used to > check the pfn validity (pfn_valid()). Since section_deactivate release > mem_section->usage if a section is fully deactivated, pfn_valid() check after > a subsection_deactivate cause a kernel crash. > > static inline int pfn_valid(unsigned long pfn) > { > ... > return early_section(ms) || pfn_section_valid(ms, pfn); > } > > where > > static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn) > { > int idx = subsection_map_index(pfn); > > return test_bit(idx, ms->usage->subsection_map); > } > > Avoid this by clearing SECTION_HAS_MEM_MAP when mem_section->usage is freed. > > Fixes: d41e2f3bd546 ("mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case") d41e2f3bd546 had cc:stable, so I shall add cc:stable to this one as well. > Cc: Baoquan He <bhe@redhat.com> > Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> > --- > mm/sparse.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/sparse.c b/mm/sparse.c > index aadb7298dcef..3012d1f3771a 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -781,6 +781,8 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages, > ms->usage = NULL; > } > memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr); > + /* Mark the section invalid */ > + ms->section_mem_map &= ~SECTION_HAS_MEM_MAP; > } > > if (section_is_early && memmap)
next prev parent reply other threads:[~2020-03-26 0:38 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-25 3:19 [PATCH] mm/sparse: Fix kernel crash with pfn_section_valid check Aneesh Kumar K.V 2020-03-25 3:19 ` Aneesh Kumar K.V 2020-03-25 6:50 ` Aneesh Kumar K.V 2020-03-25 7:06 ` Baoquan He 2020-03-25 7:06 ` Baoquan He 2020-03-25 7:37 ` Baoquan He 2020-03-25 7:37 ` Baoquan He 2020-03-25 8:12 ` Aneesh Kumar K.V 2020-03-25 8:12 ` Aneesh Kumar K.V 2020-03-25 8:36 ` Baoquan He 2020-03-25 8:36 ` Baoquan He 2020-03-26 0:38 ` Andrew Morton [this message] 2020-03-26 0:38 ` Andrew Morton 2020-03-26 9:40 ` Michal Hocko 2020-03-26 9:40 ` Michal Hocko 2020-03-26 9:56 ` Aneesh Kumar K.V 2020-03-26 9:56 ` Aneesh Kumar K.V 2020-03-26 10:16 ` Michal Hocko 2020-03-26 10:16 ` Michal Hocko 2020-03-26 10:50 ` Michal Hocko 2020-03-26 10:50 ` Michal Hocko
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=20200325173817.a63f20dd0ec618e063569e4a@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.ibm.com \ --cc=bhe@redhat.com \ --cc=david@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mhocko@suse.com \ --cc=mpe@ellerman.id.au \ --cc=osalvador@suse.de \ --cc=pankaj.gupta.linux@gmail.com \ --cc=richardw.yang@linux.intel.com \ --cc=rppt@linux.ibm.com \ --cc=sachinp@linux.vnet.ibm.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: 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.