From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4119CC77B7A for ; Tue, 16 May 2023 19:25:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8C9C900003; Tue, 16 May 2023 15:25:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3CE7900002; Tue, 16 May 2023 15:25:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DDDF900003; Tue, 16 May 2023 15:25:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7C0B0900002 for ; Tue, 16 May 2023 15:25:19 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 39765160370 for ; Tue, 16 May 2023 19:25:19 +0000 (UTC) X-FDA: 80797096758.22.6615E4D Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf24.hostedemail.com (Postfix) with ESMTP id 47BDB180014 for ; Tue, 16 May 2023 19:25:16 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fzPcKqeh; spf=pass (imf24.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684265117; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0/lEQ/IxjkAHBzjS7pPyUe2O2fy004pHzdBxS9b2Y0Y=; b=eEk6oqGPemdNedB1NMz9pbt/twRk7ExcF287k4wLOqEvtD6CnqNjDTBkaCRy0dePdbVew3 vjmIRNP1Gw1GklVg69ZiDVGhXBPjlgcCveiO5mhEqpgQlqgGlEv20zun5E8TAVgIcJFDsj ijG7nI7YwWxjaIg29Q/H9Vo0HqTjfZE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=fzPcKqeh; spf=pass (imf24.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684265117; a=rsa-sha256; cv=none; b=2WZlu2CQ/roTxygL7tZUVm53WronuFaO/IlAK9vr5OsG5ndkv34bfcNTv1nbFb2DVgy+f2 lnjQ+iKnHVzik1OpVed5tFfqDbzp3kr7+WOIZbGOfE2giflthcJ/tPJ+n4B1rMvAPkSlrv bSHL6iU0bJeHN0scQScuCRJLwhlw37M= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3093a7b71fbso649622f8f.2 for ; Tue, 16 May 2023 12:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684265115; x=1686857115; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0/lEQ/IxjkAHBzjS7pPyUe2O2fy004pHzdBxS9b2Y0Y=; b=fzPcKqehspIzdoifXtkLU1DB/yfuDvRwLgCyPkNU367n5SUS7rFix9jXcrKR+tcZfj AJzC3vv7FpDCgPatwpiGxpRpgln9isgqo3fKSJQzDaxYseyDNtyQF3GpiIFwH5EP7xh3 V83QyEHhGLRbKeKdF8b0iKKA2WAlPs/xDoZab7NhbNh3xyArTgp1RQ6gfn99/56DeGqz 9kKr8l5i3Re77TUH7f2au6ZlSGTrODbj/cTGW9QrPAuoAXo/5hJyRMVtRdw/9/SAHTuG meLyyRprvygmJd/JHJjz+/YXMO6lZWMmslSPH+9kpSLcY2rAIsKmoSOcu5o4++K3QoCR 6Ixg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684265115; x=1686857115; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0/lEQ/IxjkAHBzjS7pPyUe2O2fy004pHzdBxS9b2Y0Y=; b=aPVDT3jA8FeDgrJ+9hzmIZV+9Jvh1N2GagF7+c0Y+v3c3MzculnsU+kIKNU1BpWCHX xxCF0jxGzzaPc/xAn2lctq8Jzcxe8UMb+CqQ5WUf+ih5WTEYHuiAjUmxAUjYL43uyM1c blm5KTWnf8RN6IJPWJktShRxOY49rlS5mowfU20Ve8ekHY7O+bHkf0EMfs3H89K7MmhL 9DrbxE0Zpf1cdgv2sHXRvB/QtJt8nIjB5aONLFCIrs6UlTt6n+yd1py6kTn/SCmYxxL9 8cLGTtUXgS1+4Hvr6BW2eOxlbIX6X1cDczoScdf6x6t1s365ORCFsNrtXh+4sAv7AR2A JyRA== X-Gm-Message-State: AC+VfDyIFXTu3QS0tWm4YQQDP82mkdltapCmdxfhcQvqcMvkAsF7uQxy xR0ppMXHjMn3udMlKORWMsU= X-Google-Smtp-Source: ACHHUZ7roro9vpaszQqDJvdZwJL3ArC7J+WFDebVEi16EnDgkJK9z5U+cF0ev/Af0ZdI1mGQLG8AqQ== X-Received: by 2002:a5d:5003:0:b0:306:3408:f9a8 with SMTP id e3-20020a5d5003000000b003063408f9a8mr27670798wrt.11.1684265115288; Tue, 16 May 2023 12:25:15 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id o8-20020a5d6848000000b002ceacff44c7sm267720wrw.83.2023.05.16.12.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 12:25:14 -0700 (PDT) Date: Tue, 16 May 2023 20:25:13 +0100 From: Lorenzo Stoakes To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mike Rapoport , Mark Rutland , "Liam R . Howlett" , Alexander Viro , Christian Brauner Subject: Re: [PATCH v2] mm: userfaultfd: avoid passing an invalid range to vma_merge() Message-ID: <9739133c-3ee7-4e94-a6a8-783045a50ac6@lucifer.local> References: <20230515193232.67552-1-lstoakes@gmail.com> <20abea10-5307-498b-b9df-8f0b2fed1701@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 47BDB180014 X-Stat-Signature: tc9fqsu85utng3shuybfracn3x6krpt9 X-HE-Tag: 1684265116-189491 X-HE-Meta: U2FsdGVkX192bNhxOwbiFCcyHwPFfvqLRB0ItQJUL7//b7e4XDqBk/3RMUv/pSQ+DsxViYckfHYP/Mx+22m2Qr3PJNEpW4uAhwebeIYsT/RoslFn88r5h0z+w6ZaHzwxkOKzGUrZpXqkLRu3DK7Hy1GZcW+tv8RjqnJZ2Uefx5ICj0CWSxBseUIW8JK3O+8eXBPXmFjJBvn2LSrt95BGJgb/Hvue/pA5oHt04CdAXH/cdkzUOpdb34Ha71FhQs+FkAZn6OpjRwehAIytZpwXV06vkrEfOj3fbJ2iFD0o+c2hhxZG8jMCcgob/yKRwOLaXfPPQvBuzlP+Ho3Z9TzK+xwKLQYOkLLUIE0c3Fl4he8jYeNraBvdls36crIiBiChYMyoE3JC2hZVsJuwIsGffUbmDkPR+roBIIqJnYu6JcDFDggsFDhf4UheGrM6GUTqQ+ZK9cIcvbo3M+BKSAVRAZAl184D1oDHPFMEQ6WCWcERLDwZ6DEMLvw15Sv9FBd/JqKAWsRtMFzZPfwcQ4/7F3VySlHrHXCMgFLcgQZV79WbOC9nQVdDZn3Dzq7too9QdbGXzE9gl0zlRa3vKHKrilIrNT9AZnN0A5cxj8eMX9nCPfLMrztTNjj31POVpoi5mZue6RAqvbUe1hUNXRRvtt2AXRtJXmDAiooXJhwn4szvvmztxvBOW9UkUc4mU28o4qo8YedXUzUV40gIEg3ZkE7dISUBsP6Fkzd+/MZId8NohCV4UtHi7vhN1aaJKWMKfk/CrWrPiiazEJAawy9HegdQe2pk7nPPIfjCnKvqTNQF+31K6Aqg/D2oorK3VCs3CMhixLogwWRVkchDJGehSF8r8DTeyQhipbb2xQqkvM62O2oyEsx5VnTjImjzJm6rvBesGCHHZh1It82FP59SRGDTe1GXUnqHiwkCDB/31gT0o+lHzKig44rNNE5lc4aaLKKK78mHbdgWwjWE/Nl EK33X+tt 95ck/NQ5J6urXBh93MMpty7XRbY1WSejXzuEED189qgZBvZl0fzDL+LVx/1iYcqAfKXN7Q6T1TykGpid4RgKacrv7fLWP2DcTEFn/51e3IugklMnKIK/P6XY76t+Ln9pnv5GTcGKo4ZHRrkQoLL854u8HWbBQWVdHewcDx4FJIY5UXwBxMahS5bQdr7JxgE0PIK4TIZKLDbhc8nEYsEtz5iNdDkqG8HyL19469di7+c2HUHFaLoremx5wwFilsD4qH1mp8LOqUsvtfVhzrZZ0P5FhpdAa3NyZLpCDoD/vgSag4PeFb6FhF4Oz7vcyFUBdD0QsbXBPt+gerA06/jNB08mCErYGqb0lu7aCLJdSAf/+0JzL6WuoSaYo9waV+2kwU/7UjwuBZ9GcRvjizqzaTf1/F34W3kNZcjWvcPY/nSvbGCbdBU+lVQ6RI2IEBJ4JkCpUfIknzRPza90EDJVjVY0Cg7lcQBEiWQYFWHNAF2RoFEZ4lXH3KGEk1I/PRfzeuYAlpqzgsK/1kqxR/iHVBtQpJBhe8Xfeucs1extC0ueXZeUABsbc1g3i8Lp7cSHP+oUj1Rov1rtb8A4Xjr/vJt7RTz+NGzW70h/1C7ooZJz+wOxwUE8Lt8HiUA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 16, 2023 at 11:06:40AM -0400, Peter Xu wrote: > On Tue, May 16, 2023 at 12:07:11AM +0100, Lorenzo Stoakes wrote: > > On Mon, May 15, 2023 at 11:04:27PM +0100, Lorenzo Stoakes wrote: > > [snip] > > > > Could you explain a bit why we don't need to merge in this case? > > > > > > > > I'm considering, for example, when we have: > > > > > > > > vma1(range 0-9, with uffd), vma2(range 10-19, no uffd) > > > > > > > > Then someone unregisters uffd on range (5-9), iiuc it should become: > > > > > > > > vma1(range 0-4, with uffd), vma2(range 5-19, no uffd) > > > > > > > > But if no merge here it's: > > > > > > > > vma1(range 0-4, with uffd), vma3(range 5-9, no uffd), vma2(range 10-19, no uffd) > > > > > > > > Maybe I missed something? > > > > > > > > > > There's something really, really wrong with this. It simply isn't valid to > > > invoke vma_merge() over an existing VMA that != prev where you're not > > > specifying addr = vma->vm_start, end == vma->vm_end. > > > > > > This seems like you're relying on:- > > > > > > *** > > > CCCCCNNNNN -> CCNNNNNNNN > > I had a closer look today, I still think this patch is not really the right > one. The split/merge order is something we use everywhere and I am not > convinced it must change as drastic. At least so far it still seems to me > if we do with what current patch proposed we can have vma fragmentations. 'something we use everywhere' is not an argument (speak to Willy about folios), vma_merge() expects valid input, relying on it _happening_ to be ok or to fail in ways that _happen_ not to cause big problems is not right. This is just further evidence that the vma_merge() interface is fundamentally broken. Implicitly assuming you will only get a partial prev overlap merge is far from intuitive. I am definitely going to try to do a series addressing vma_merge() horrors because I feel like we need a generic means of doing this split/merge pattern. > > I think I see what you meant, but here I think it's a legal case where we > should have PPPP rather than CCCC (PPPPPNNNN --> PPNNNNNNNN). > > To be explicit, for register I think it _should_ be the case 0 where we > cannot merge (note: the current code is indeed wrong though, see below): > > **** > PPPPPPNNNNNN > cannot merge > > While for the unregister case here it's case 4: > > **** > PPPPPPNNNNNN > might become > PPNNNNNNNNNN > case 4 below > > Here the problem is not that we need to do split then merge (I think it'll > have the problem of vma defragmentation here), the problem is we simply > passed in the wrong "prev" vma pointer, IMHO. I've patches attached > showing what I meant. Yeah if you do it with prev = vma this form should _probably_ work, that's a good point. This _is_ a case (see https://ljs.io/vma_merge_cases.png for nice diagram of cases btw :), like 5, where we actually do split and merge at the same time. Liam's raised some issues with the safety of your patches, let me look at them when I get a chance, nasty headcold = brain less functional atm. I would say for now this fix resolves the issue in a way that should emphatically avoid invalid input to vma_merge(), the fragmentation existed before so this is not a new issue, so for the time being I think it's ok to stay as-is. > > I checked the original commit from Andrea and I found that it _was_ correct: > > commit 86039bd3b4e6a1129318cbfed4e0a6e001656635 > Author: Andrea Arcangeli > Date: Fri Sep 4 15:46:31 2015 -0700 > > userfaultfd: add new syscall to provide memory externalization > > I had a feeling that it's broken during the recent rework on vma (or maybe > even not that close), but I'm not yet sure and need to further check. > > > > > > > By specifying parameters that are compatible with N even though you're only > > > partially spanning C? > > > > > > This is crazy, and isn't how this should be used. vma_merge() is not > > > supposed to do partial merges. If it works (presumably it does) this is not > > > by design unless I've lost my mind and I (and others) have somehow not > > > noticed this?? > > > > > > I think you're right that now we'll end up with more fragmentation, but > > > what you're suggesting is not how vma_merge() is supposed to work. > > > > > > As I said above, giving vma_merge() invalid parameters is very dangerous as > > > you could end up merging over empty ranges in theory (and could otherwise > > > have corruption). > > > > > > I guess we should probably be passing 0 to the last parameter in > > > split_vma() here then to ensure we do a merge pass too. Will experiment > > > with this. > > > > > > I'm confused as to how the remove from case 8 is not proceeding. I'll look > > > into this some more... > > > > > > Happy to be corrected if I'm misconstruing this! > > > > > > > OK, so I wrote a small program to do perform exactly this case [0] and it seems > > that the outcome is the same before and after this patch - vma_merge() is > > clearly rejecting the case 8 merge (phew!) and in both instances you end up with > > 3 VMAs. > > > > So this patch doesn't change this behaviour and everything is as it was > > before. Ideally we'd let it go for another pass, so maybe we should change the > > split to add a new VMA _afterwards_. Will experiment with that, separately. > > > > But looks like the patch is good as it is. > > > > (if you notice something wrong with the repro, etc. do let me know!) > > > > [0]: https://gist.github.com/lorenzo-stoakes/a11a10f5f479e7a977fc456331266e0e > > I think your test case is fine, but... no, this is still not expected. The > vma should just merge. > > So I have another closer look on this specific issue, it seems we have a > long standing bug on pgoff calculation here when passing that to > vma_merge(). I've got another patch attached to show what I meant. > > To summarize.. now I've got two patches attached: > > Patch 1 is something I'd like to propose to replace this patch that fixes > incorrect use of vma_merge() so it should also eliminate the assertion > being triggered (I still think this is a regression but I need to check > which I will do later; I'm not super familiar with maple tree work, maybe > you or Liam can quickly spot). > > Patch 2 fixes the long standing issue of vma not being able to merge in > above case, and with patch 2 applied it should start merging all right. > > Please have a look, thanks. > > ---8<--- > From 6bc39028bba246394bb0bafdaeaab7b8dfd1694f Mon Sep 17 00:00:00 2001 > From: Peter Xu > Date: Tue, 16 May 2023 09:03:22 -0400 > Subject: [PATCH 1/2] mm/uffd: Fix vma operation where start addr cuts part of > vma > > It seems vma merging with uffd paths is broken with either > register/unregister, where right now we can feed wrong parameters to > vma_merge() and it's found by recent patch which moved asserts upwards in > vma_merge(): > > https://lore.kernel.org/all/ZFunF7DmMdK05MoF@FVFF77S0Q05N.cambridge.arm.com/ > > The problem is in the current code base we didn't fixup "prev" for the case > where "start" address can be within the "prev" vma section. In that case > we should have "prev" points to the current vma rather than the previous > one when feeding to vma_merge(). > > This will eliminate the report and make sure vma_merge() calls will become > legal again. > > Signed-off-by: Peter Xu > --- > fs/userfaultfd.c | 27 +++++++++++++++++++++------ > 1 file changed, 21 insertions(+), 6 deletions(-) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index 0fd96d6e39ce..7eb88bc74d00 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -1458,10 +1458,17 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, > BUG_ON(!found); > > vma_iter_set(&vmi, start); > - prev = vma_prev(&vmi); > + vma = vma_find(&vmi, end); > + if (!vma) > + goto out_unlock; > + > + if (vma->vm_start < start) > + prev = vma; > + else > + prev = vma_prev(&vmi); > > ret = 0; > - for_each_vma_range(vmi, vma, end) { > + do { > cond_resched(); > > BUG_ON(!vma_can_userfault(vma, vm_flags)); > @@ -1517,7 +1524,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, > skip: > prev = vma; > start = vma->vm_end; > - } > + } for_each_vma_range(vmi, vma, end); > > out_unlock: > mmap_write_unlock(mm); > @@ -1624,9 +1631,17 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > BUG_ON(!found); > > vma_iter_set(&vmi, start); > - prev = vma_prev(&vmi); > + vma = vma_find(&vmi, end); > + if (!vma) > + goto out_unlock; > + > + if (vma->vm_start < start) > + prev = vma; > + else > + prev = vma_prev(&vmi); > + > ret = 0; > - for_each_vma_range(vmi, vma, end) { > + do { > cond_resched(); > > BUG_ON(!vma_can_userfault(vma, vma->vm_flags)); > @@ -1692,7 +1707,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > skip: > prev = vma; > start = vma->vm_end; > - } > + } for_each_vma_range(vmi, vma, end); > > out_unlock: > mmap_write_unlock(mm); > -- > 2.39.1 > > From bf61f3c937e9e2ab96ab2bed0005cb7dc74db231 Mon Sep 17 00:00:00 2001 > From: Peter Xu > Date: Tue, 16 May 2023 09:39:38 -0400 > Subject: [PATCH 2/2] mm/uffd: Allow vma to merge as much as possible > > We used to not pass in the pgoff correctly when register/unregister uffd > regions, it caused incorrect behavior on vma merging. > > For example, when we have: > > vma1(range 0-9, with uffd), vma2(range 10-19, no uffd) > > Then someone unregisters uffd on range (5-9), it should become: > > vma1(range 0-4, with uffd), vma2(range 5-19, no uffd) > > But with current code it's: > > vma1(range 0-4, with uffd), vma3(range 5-9, no uffd), vma2(range 10-19, no uffd) > > This patch allows such merge to happen correctly. > > This behavior seems to have existed since the 1st day of uffd, keep it just > as a performance optmization and not copy stable. > > Cc: Andrea Arcangeli > Cc: Mike Rapoport (IBM) > Signed-off-by: Peter Xu > --- > fs/userfaultfd.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index 7eb88bc74d00..891048b4799f 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -1332,6 +1332,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, > bool basic_ioctls; > unsigned long start, end, vma_end; > struct vma_iterator vmi; > + pgoff_t pgoff; > > user_uffdio_register = (struct uffdio_register __user *) arg; > > @@ -1489,8 +1490,9 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, > vma_end = min(end, vma->vm_end); > > new_flags = (vma->vm_flags & ~__VM_UFFD_FLAGS) | vm_flags; > + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT); > prev = vma_merge(&vmi, mm, prev, start, vma_end, new_flags, > - vma->anon_vma, vma->vm_file, vma->vm_pgoff, > + vma->anon_vma, vma->vm_file, pgoff, > vma_policy(vma), > ((struct vm_userfaultfd_ctx){ ctx }), > anon_vma_name(vma)); > @@ -1570,6 +1572,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > unsigned long start, end, vma_end; > const void __user *buf = (void __user *)arg; > struct vma_iterator vmi; > + pgoff_t pgoff; > > ret = -EFAULT; > if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) > @@ -1677,8 +1680,9 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > uffd_wp_range(vma, start, vma_end - start, false); > > new_flags = vma->vm_flags & ~__VM_UFFD_FLAGS; > + pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT); > prev = vma_merge(&vmi, mm, prev, start, vma_end, new_flags, > - vma->anon_vma, vma->vm_file, vma->vm_pgoff, > + vma->anon_vma, vma->vm_file, pgoff, > vma_policy(vma), > NULL_VM_UFFD_CTX, anon_vma_name(vma)); > if (prev) { > -- > 2.39.1 > ---8<--- > > -- > Peter Xu >