On Thu, Sep 28, 2023 at 11:43 AM Peter Xu peterx@redhat.com wrote:
One more thing..
On Fri, Sep 22, 2023 at 06:31:45PM -0700, Suren Baghdasaryan wrote:
+static int remap_pages_pte(struct mm_struct *dst_mm,
[...]
+retry:
dst_pte = pte_offset_map_nolock(dst_mm, dst_pmd, dst_addr, &dst_ptl);/* If an huge pmd materialized from under us fail */if (unlikely(!dst_pte)) {err = -EFAULT;goto out;}src_pte = pte_offset_map_nolock(src_mm, src_pmd, src_addr, &src_ptl);/** We held the mmap_lock for reading so MADV_DONTNEED* can zap transparent huge pages under us, or the* transparent huge page fault can establish new* transparent huge pages under us.*/if (unlikely(!src_pte)) {err = -EFAULT;goto out;}For these two places: I know that thp collapse with mmap read lock hasn't yet spread to anon (so I assume none of above could trigger yet on the failure paths), but shall we constantly return -EAGAIN here just in case we forget that in the future?
For example, for UFFDIO_COPY over shmem which we can already hit similar case, mfill_atomic_install_pte() has:
ret = -EAGAIN; dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl); if (!dst_pte) goto out;Thanks,
Retrying in this case makes sense to me. Will change.
-- Peter Xu
-- To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.