lkml.org 
[lkml]   [2023]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: hugetlb_vmemmap: fix a race between vmemmap pmd split
On 07/07/23 11:38, Muchun Song wrote:
> The local variable @page in __split_vmemmap_huge_pmd() to obtain a pmd
> page without holding page_table_lock may possiblely get the page table
> page instead of a huge pmd page. The effect may be in set_pte_at()
> since we may pass an invalid page struct, if set_pte_at() wants to
> access the page struct (e.g. CONFIG_PAGE_TABLE_CHECK is enabled), it
> may crash the kernel. So fix it. And inline __split_vmemmap_huge_pmd()
> since it only has one user.
>
> Fixes: d8d55f5616cf ("mm: sparsemem: use page table lock to protect kernel pmd operations")
> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> ---
> mm/hugetlb_vmemmap.c | 34 ++++++++++++++--------------------
> 1 file changed, 14 insertions(+), 20 deletions(-)

Sorry, for the very late reply!

This code looks fine to me,
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>

The discussion about 'open code' or inline' has me a bit confused. I am
perfectly happy with the code as it is.

When I hear/see inline, I think of the inline function keyword. Since that
is not happening in this patch, the mention of 'inline
__split_vmemmap_huge_pmd()' does cause me to think a bit more than usual.

Yes, the backports will need to be modified.
--
Mike Kravetz

\
 
 \ /
  Last update: 2023-08-15 00:31    [W:0.063 / U:1.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site