> On Sep 24, 2024, at 14:09, Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> Reviewed-by: Muchun Song <muchun.song@xxxxxxxxx>
