linux-kernel - Re: [PATCH v4 01/13] mm: pgtable: introduce pte_offset_map_{ro|rw}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4D6AAB88-6BA9-4F7E-9EEA-829640D1BDDF@linux.dev>
Date: Tue, 24 Sep 2024 14:24:27 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: Qi Zheng <zhengqi.arch@...edance.com>
Cc: david@...hat.com,
 hughd@...gle.com,
 willy@...radead.org,
 vbabka@...nel.org,
 akpm@...ux-foundation.org,
 rppt@...nel.org,
 vishal.moola@...il.com,
 peterx@...hat.com,
 ryan.roberts@....com,
 christophe.leroy2@...soprasteria.com,
 linux-kernel@...r.kernel.org,
 linux-mm@...ck.org,
 linux-arm-kernel@...ts.infradead.org,
 linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v4 01/13] mm: pgtable: introduce
 pte_offset_map_{ro|rw}_nolock()



> On Sep 24, 2024, at 14:09, Qi Zheng <zhengqi.arch@...edance.com> wrote:
> 
> Currently, the usage of pte_offset_map_nolock() can be divided into the
> following two cases:
> 
> 1) After acquiring PTL, only read-only operations are performed on the PTE
>   page. In this case, the RCU lock in pte_offset_map_nolock() will ensure
>   that the PTE page will not be freed, and there is no need to worry
>   about whether the pmd entry is modified.
> 
> 2) After acquiring PTL, the pte or pmd entries may be modified. At this
>   time, we need to ensure that the pmd entry has not been modified
>   concurrently.
> 
> To more clearing distinguish between these two cases, this commit
> introduces two new helper functions to replace pte_offset_map_nolock().
> For 1), just rename it to pte_offset_map_ro_nolock(). For 2), in addition
> to changing the name to pte_offset_map_rw_nolock(), it also outputs the
> pmdval when successful. It is applicable for may-write cases where any
> modification operations to the page table may happen after the
> corresponding spinlock is held afterwards. But the users should make sure
> the page table is stable like checking pte_same() or checking pmd_same()
> by using the output pmdval before performing the write operations.
> 
> Note: "RO" / "RW" expresses the intended semantics, not that the *kmap*
> will be read-only/read-write protected.
> 
> Subsequent commits will convert pte_offset_map_nolock() into the above
> two functions one by one, and finally completely delete it.
> 
> Signed-off-by: Qi Zheng <zhengqi.arch@...edance.com>

Reviewed-by: Muchun Song <muchun.song@...ux.dev>