Messages in this thread | | | Date | Mon, 14 Aug 2023 15:28:39 -0700 | From | Mike Kravetz <> | Subject | Re: [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
| |