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 816FDC46CA1 for ; Mon, 18 Sep 2023 21:20:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB8F66B0454; Mon, 18 Sep 2023 17:20:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C68F86B0456; Mon, 18 Sep 2023 17:20:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B30E46B0457; Mon, 18 Sep 2023 17:20:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A1AFA6B0454 for ; Mon, 18 Sep 2023 17:20:37 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 70BB8B3BC1 for ; Mon, 18 Sep 2023 21:20:37 +0000 (UTC) X-FDA: 81250987314.11.0C47CB4 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf14.hostedemail.com (Postfix) with ESMTP id B014F100005 for ; Mon, 18 Sep 2023 21:20:35 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="djO/5Ijo"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695072035; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dq0Us6jgc8KxbneLdF2D9i/7B/TB9s9lbtLNUZgPGF4=; b=rj4dM6W7zapM4ZyNs6pIwuIwzHKtP/qcTd25ZPK6E2mXMou81GScqV1rXxkZaW0rUmIf37 24gmEy3Ii94eImpIrKpjiWqbGhxJ9JofnOGHmYw9j57oxI8Vp9Rx+F8NDtp16Fqb7GiN8+ 22k+7RbP5HFqx3sQfnILUzvikuohIZY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="djO/5Ijo"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695072035; a=rsa-sha256; cv=none; b=b/kcYtaMknntyUfIe1aN6nZSTlL4SqZ2LbeGyCzHNMN1R9fwKgyFUuT0nCnajhuz2EyG7H cw/1krnxPSfhrvEUCZSACmMIDtgsZnTDtQmORcb3tVQS4WcIngC9FyG+E3x0PhSrabinqt XQZjoi0Z2ikiihP9ifFtV0MSfd8+X0A= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-59be6605e1dso53912697b3.3 for ; Mon, 18 Sep 2023 14:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695072035; x=1695676835; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dq0Us6jgc8KxbneLdF2D9i/7B/TB9s9lbtLNUZgPGF4=; b=djO/5IjouDMXcMunmpyltDWX89/zxWyBwCz/qB0cosf0Rf80FaQM5V4CtBkyRsOQAE RC9vzTsqyOKWFdjuIeDzlj3keQsBecEeHAe8jqn6dRNUgrn6lB6TdPHKsyW8+HLepW8Z Pigb4oPmEIrXZdgqnnw2Jp6TRL2ycBSOcGnkuTyiewyHFcgvljvqK7IcSSYq/JU/o/zQ ew8ORMR0OBUhl5DSZ6AtkmdnPkdC01lq3doEYB1wqB/KbJzfxQVJO6KAtvG//zLqfSA7 pKJDyK2l2gqmN1WRJtqnRXlR/fIRgoPoR+X+2k5ajoxvuscqeyvKS3Rx64B4Y9BJiOZE rjwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695072035; x=1695676835; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dq0Us6jgc8KxbneLdF2D9i/7B/TB9s9lbtLNUZgPGF4=; b=SskEeWsEqgkgnDk9I40tjobPMe/D8HAi2nvD5s3eNk+3V8XOeoxm0+ky2SPQCRlu1g m7CuMnQg8UjaghxTw9RzK3/3j8NY62EPL3tFcezjFQMkDXQ6vof15RrvXbYMW0CSfhv0 /3VzCGV45nOlDSIEZ2erC8muzCKC3cRBxcJE2okU8pm5xX3m1y55TNN+CNC7tj0rSFkF AE2v3N1v8dUXy1Wte1dHXMKeqFgEby8xm2zq4YB+BveAvgtde7xUeXpCHGbH6NMYGlzq EA2Dd6tTG5Mf8i4yhLMU2cvQRkXmfR8ni5gDswjsjsv11TMK+8n2J4OhRdb46Idvq5z/ i6OQ== X-Gm-Message-State: AOJu0YzeaMPaecbtfnat3vfk/9n7XwJRRwd1YXQeLSFk2QPwOCrJuxhg LE8E+/8+Udjbm3h1y6TbjjFl9+hF1V5CPS1w5XLfJA== X-Google-Smtp-Source: AGHT+IGp/f9+93JwB0m2FgNAnlhhWWRiePhsGkj7brQqYKXV1+s/tl82YUmWcmyaM3pHlbm2zeMDDYLx5IjwXU5YkD0= X-Received: by 2002:a0d:cb51:0:b0:59b:d899:f171 with SMTP id n78-20020a0dcb51000000b0059bd899f171mr9736557ywd.1.1695072034557; Mon, 18 Sep 2023 14:20:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Mon, 18 Sep 2023 14:20:21 -0700 Message-ID: Subject: Re: [syzbot] [mm?] kernel BUG in vma_replace_policy To: Hugh Dickins Cc: Matthew Wilcox , Yang Shi , Michal Hocko , Vlastimil Babka , syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B014F100005 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 1e3mhqj6yd3bhzsuqc7ukxtaed84fstn X-HE-Tag: 1695072035-88104 X-HE-Meta: U2FsdGVkX19kiz73RtL1t6IoIYBL1hf66Rsvzp1Rl4kPx106GWACy4oGo0RFPGQaxd6qxz/n8udRZce7e7s6TYeipuprwZPweJ/SBNWlFZJcaXmJaV0y3OG651SOVyrCyROHFVekf9LoWAhCJ8nHlfO20TvVTQmo5x99EfTrzKs76suUdCVjWvjq3zT9vxY7zIPhgCKs1K+QwjMXFqcV4xRY5EN2lzsF0i6zRAap3KxWoFWtkkklwsjz9IhnELm7u4HOgJgPHfFKdQHGRb/T68CPFig42LrL65m/M7ZgKNauqbgKKXdnj2lpbwEadit/jXomYX83UxFNH2yceQgiYnfasXVKAZvgBYpM6fUw4jmtGCWuhEUF/iFJxyJ9WYeQDIRitP5tjclk58IeBuheHL/aeIWlbrBkY+C3ih21prGc3GWvObTsXiELNgUxi9izzB+feKSxXWnlIFnIe9AFAk0D3mmaZ1AxA7e0ocu6ujro6007qxRyOzJ4naWh/wFqPybyGj4PfE3S2opSQUvjWTW5OhtU5aiIGx9Ax4NxKdNP3Uchyed5kh6g+CcjWJPAKuqUnK5PR4/OsSCi2kHVjSBcvog0GgQTtEDr0sQiwrZlPr6rAj+kYgrg7g4UMsL5NZZIxn9EGFlOuLkShOCU6JAkFu/AvevXMziAYJml/CmvftrjRtCQTM5cevoqxtzYr+4Ut58oA9kSnAnkfpw9KPh3uZQXjHwu0FdXRaVSCxy9WidOgiaMPZ/eStoASI6xMedX7j0E4yjJF5COzg9b4hoktl7qls6XoczEqYanEDW6ARG0BZrxV2OYAdn9uoBXyNGv9wYqymMM75rEZ2HUT3ZSl5NTpAoXtxhuT7QA+2aIURIqChKJGz89dAQZI5hEXuxQKd9/Nti6wsDiV6JDLo5IGCAoxd1QcN3li2x9lSVsWYADuqL10oECnWuTct4mZd+e/HWKUbFD8rsuwCG I75fxr4x iJvTJCzIDMiRV+sw51/PvtfCVxFfNerNbOiqBpaAs40QEyPGRPGTpRX/MhFM9+F+97CaKjlXVhsFKkpyxf5LeZaUiyARzfwExm2gViOiP5H2DQxTH0IqkKCQv7eMnVYpKHFCpQLbKyKPm144KyfbfyxZNmaSABojvnR/p+X5L4xVwU+MZ3cM3cawKfY03CrmxfabwDQuUxduNtFw+la8l0+0byf9RnlpX1BWsfwYze5eFmMvtZd5Ll4s6ElhRC7g3iOhcp0keQl4SjaVJb0aHgl3rsVWEWQrBFtepbwrqvUIKS7I/So+bRJJZIHiBblxxcbCkYjEqDTIIXvuEcPS/0MJdSmzIMSkbXQGTpS7ksyE9ak47F7Cg38L6lEF65EIMNUbmkfY6aqlmjSEVLyVMQuO8/lKZdCM/rBRa0DqgtLT3InSn7HdYvlLp3OWtJQ66CijdpyfrRF55YEPV7Vd5exzPQA/L02akjWuLa2PtajPiBMDpoj3DJ+osow== 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 Fri, Sep 15, 2023 at 7:44=E2=80=AFPM Hugh Dickins wro= te: > > On Fri, 15 Sep 2023, Suren Baghdasaryan wrote: > > On Fri, Sep 15, 2023 at 9:09=E2=80=AFAM Suren Baghdasaryan wrote: > > > > > > Thanks for the feedback, Hugh! > > > Yeah, this positive err handling is kinda weird. If this behavior (do > > > as much as possible even if we fail eventually) is specific to mbind(= ) > > > then we could keep walk_page_range() as is and lock the VMAs inside > > > the loop that calls mbind_range() with a condition that ret is > > > positive. That would be the simplest solution IMHO. But if we expect > > > walk_page_range() to always apply requested page_walk_lock policy to > > > all VMAs even if some mm_walk_ops returns a positive error somewhere > > > in the middle of the walk then my fix would work for that. So, to me > > > the important question is how we want walk_page_range() to behave in > > > these conditions. I think we should answer that first and document > > > that. Then the fix will be easy. > > > > I looked at all the cases where we perform page walk while locking > > VMAs and mbind() seems to be the only one that would require > > walk_page_range() to lock all VMAs even for a failed walk. > > Yes, I can well believe that. > > > So, I suggest this fix instead and I can also document that if > > walk_page_range() fails it might not apply page_walk_lock policy to > > the VMAs. > > > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > > index 42b5567e3773..cbc584e9b6ca 100644 > > --- a/mm/mempolicy.c > > +++ b/mm/mempolicy.c > > @@ -1342,6 +1342,9 @@ static long do_mbind(unsigned long start, > > unsigned long len, > > vma_iter_init(&vmi, mm, start); > > prev =3D vma_prev(&vmi); > > for_each_vma_range(vmi, vma, end) { > > + /* If queue_pages_range failed then not all VMAs > > might be locked */ > > + if (ret) > > + vma_start_write(vma); > > err =3D mbind_range(&vmi, vma, &prev, start, end, new)= ; > > if (err) > > break; > > > > If this looks good I'll post the patch. Matthew, Hugh, anyone else? > > Yes, I do prefer this, to adding those pos ret mods into the generic > pagewalk. The "if (ret)" above being just a minor optimization, that > I would probably not have bothered with (does it even save any atomics?) > - but I guess it helps as documentation. > > I think it's quite likely that mbind() will be changed sooner or later > not to need this; but it's much the best to fix this vma locking issue > urgently as above, without depending on any mbind() behavioral discussion= s. I posted this patch at https://lore.kernel.org/all/20230918211608.3580629-1-surenb@google.com/ to fix the immediate problem. Thanks! > > Thanks, > Hugh