[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17256b99-ab26-4f7b-9100-2fc42b233af2@redhat.com>
Date: Fri, 26 Jul 2024 10:04:46 +0200
From: David Hildenbrand <david@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>, linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Muchun Song <muchun.song@...ux.dev>, Peter Xu <peterx@...hat.com>,
Oscar Salvador <osalvador@...e.de>, stable@...r.kernel.org
Subject: Re: [PATCH v1 2/2] mm/hugetlb: fix hugetlb vs. core-mm PT locking
>>
>>> + *
>>> + * If that does not hold for an architecture, then that architecture
>>> + * must disable split PT locks such that all *_lockptr() functions
>>> + * will give us the same result: the per-MM PT lock.
>>> + */
>>> + if (huge_page_size(h) < PMD_SIZE)
>>> + return pte_lockptr(mm, pte);
>>> + else if (huge_page_size(h) < PUD_SIZE)
>>> return pmd_lockptr(mm, (pmd_t *) pte);
>>
>> IIUC, as I said above, this change doesn't fix the inconsistent lock for
>> cont-PMD size hugetlb for GUP, and it will also break the lock rule for
>> unmapping/migrating a cont-PMD size hugetlb (use mm->page_table_lock
>> before for cont-PMD size hugetlb before).
>
> After more thinking, I realized I confused the PMD table with the PMD
> entry. Therefore, using the PMD table's lock is safe for cont-PMD size
> hugetlb. This change looks good to me. Sorry for noise.
>
Thanks for the review, highly appreciated!
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists