On Thu, May 25, 2023 at 2:16 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > On Wed, 24 May 2023, Yang Shi wrote: > > On Tue, May 23, 2023 at 9:26 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > > On Mon, 22 May 2023, Yang Shi wrote: > > > > > > > For other unstable cases, it will return -ENOMEM instead of -EBUSY. > > > > > > I don't think so: the possibly-failing __pte_alloc() only gets called > > > in the pmd_none() case. > > > > I mean what if pmd is not none for huge zero page. If it is not > > pmd_none pte_alloc() just returns 0, > > Yes, I agree with you on that. > > > then returns -ENOMEM instead of -EBUSY. > > But disagree with you on that. > > return pte_alloc(mm, pmd) ? ERR_PTR(-ENOMEM) : > follow_page_pte(vma, address, pmd, flags, &ctx->pgmap); > > Doesn't that say that if pte_alloc() returns 0, then follow_page_mask() > will call follow_page_pte() and return whatever that returns? Err... you are right. I misread the code. Anyway it returns -ENOMEM instead of -EBUSY when pmd is none and pte alloc fails. Returning -ENOMEM does make sense for this case. Is it worth some words in the commit log for the slight behavior change? > > > Or it is impossible that pmd end up being pmd_huge_trans or > > !pmd_present? It should be very unlikely, for example, migration does > > skip huge zero page, but I'm not sure whether there is any corner case > > that I missed. > > I'm assuming both are possible there (but not asserting that they are). > > Hugh
