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 DAE0FCD37B0 for ; Sat, 16 Sep 2023 02:44:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EA266B0440; Fri, 15 Sep 2023 22:44:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19A7D6B0441; Fri, 15 Sep 2023 22:44:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B0FD6B0442; Fri, 15 Sep 2023 22:44:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id F0DF36B0440 for ; Fri, 15 Sep 2023 22:44:14 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B52741407A5 for ; Sat, 16 Sep 2023 02:44:14 +0000 (UTC) X-FDA: 81240916428.08.BB83110 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) by imf22.hostedemail.com (Postfix) with ESMTP id F3C92C0009 for ; Sat, 16 Sep 2023 02:44:11 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zYeWEG1f; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694832252; 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=ISPnyLNUfhuOEH21ItuTRLONf/o/+Vp6ZXvrFb0oXUg=; b=2uPtY5ahtaj6x7O+2k+peTSnMOvnpLLSLwbjI0g7V/8W6zir7UCuMiRgp2i2DxwyRkfgOO ST02pVXzJrX68uIfuYaO6nvMWBHHLxRgqXWRCfxCYideXp1UrOTfCIn9QrGOanp2dZae3Z 6afI1QnLKZg/DDFeE3PLzD1ircutgRs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zYeWEG1f; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.128.176 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694832252; a=rsa-sha256; cv=none; b=wAI2+d1WHh0mdqYEYdbQoWHysmA47j08aXXv9xnptmBNgsgO6IWBaJtQoGHvzEIV2ILGYZ wsWZTybyrO9xYJRyrjAEHxBf9dVIfAfibHe9G1WOV/oitH+VIg118am4CCtwNRHupKI200 QMqF4qLGpZunJ5n6TPIJWTslTe2dQNY= Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-58dce1f42d6so52694957b3.0 for ; Fri, 15 Sep 2023 19:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694832251; x=1695437051; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=ISPnyLNUfhuOEH21ItuTRLONf/o/+Vp6ZXvrFb0oXUg=; b=zYeWEG1fOMfTcfMm/WV+Dipfwj/x9orKso0WIjnFI7IPcJ50ABQvoQYPBc/Ji3y4ke Aq9wQzpNSFtt/o3h3z3fTMHNmw2Yr4/GZgsPYxAa8pecVIbl6ruPJEdzz5OeeG53i2bd Outb4xrQkUGVOU6XQfO0PXKT76aPNMRvddloLod+Z78eKy8POWNVIIDP62h2rAbiW96C Xv3dK6/UDBC4wzb3aI8pXrOuwhYCgl50iVq20bSobpLMnAqSpZ26oAsMrubQxz2c1H0r tyPOr7tdTzmcPWNBdvzPq+rOplSa0isQun8Z7hY6cT4pCD2kAHbTi8sU9+i3zqCPCfyN Qe+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694832251; x=1695437051; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ISPnyLNUfhuOEH21ItuTRLONf/o/+Vp6ZXvrFb0oXUg=; b=fYMbD2dxlJ2WO+5LHK/UK6be5AOxs1Ss8NQdjmhwK8l47VFbZK7myGJy3bEL/qsmU7 BffPNQA0Jj2ax77tEPmM1C6A4BNDojeBxBOHh8FY5q44XM4bZ9zgzgEL+ssSalQixA13 pUE4W0qoHGj4Q5YiBoUY1R7JRQQ4L3I/3EjvQN29ol4+neOaHqM8RQU7bwzyOd+79YuZ 6YwSpdmfK7plKtLhBtENu2RbnU3LU4Gja+r8FOogNLti3neaNOaILSeMPHFn1+oLPKXL vy71SrZ/Hy6HzR7+YxgoM3IHsa4SyxZnQVxsyjKiq7szUCWk5L9xLvsbDIwZcFyGc8LD 14ig== X-Gm-Message-State: AOJu0YxYUDqwn0Vt1zR72rA9ig2OdWpKR2+YV+B1jMgJqrf0zASevGyy 0rCBhXVvrH3HMtwDA0dmSFu8zA== X-Google-Smtp-Source: AGHT+IGkD9tRpts+Kot+QJ/QB//55QmamJf5bkfILtPqQYnfwt1OagBcnZkLMkIDPTkUlIdrBRajkg== X-Received: by 2002:a81:6d0f:0:b0:59b:e9d5:a41c with SMTP id i15-20020a816d0f000000b0059be9d5a41cmr3982610ywc.22.1694832251056; Fri, 15 Sep 2023 19:44:11 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id q5-20020a815c05000000b0058fc7604f45sm1182997ywb.130.2023.09.15.19.44.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 19:44:10 -0700 (PDT) Date: Fri, 15 Sep 2023 19:43:58 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Suren Baghdasaryan cc: Hugh Dickins , 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 Subject: Re: [syzbot] [mm?] kernel BUG in vma_replace_policy In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463760895-168202884-1694832249=:16517" X-Rspamd-Queue-Id: F3C92C0009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 4be1fe41y3m8i4iwm3h9h933jxgirt17 X-HE-Tag: 1694832251-507500 X-HE-Meta: U2FsdGVkX1+ORlr7tbm61FvyiFohJKdXp/WZ9SP1veigF1Whd4vIZvOrQYrvnnJ0YtN3fJ1eGCHSv2yBzSk8eldIRrzum6xAEZF73j8RKtz9C69tLMCykEU/DYj7XAGm795VC5HRX02P4ZPJDNjl84+tZuY7U/dyV3srqJFH5kmw9FE0mC3cgsgYTsp6m0qOXKMBsHzm88P3DSO6WjSVOHXFSsY28VaeVo1lx9ThY5H2AhGK+AGena1atyM4VpYVrwpZt8x5D9G2JvHQCXSw43CeVzsxBKpGn1EdbZ9GqMDuqF5In8wZr0bJvHXO8ZY4WMZTKXj+LEISmTefZ+WpiSTMWW5f9H2vnMam++bieOLxzp/mozOoSX96jaUf9KKcrieR2I1tF58TMHrpeBPzVwwe8PKhOGWYWFz7PoXT7LCLCt+X4vp0EkRVhpcwDEUWH1J80N3ci7CH2CVptsiocxmLsCrSMBQDBSTlbpu5bDjKzIQbLLZiG8Fq7/Wdjs7i6tbMeESSeurNmVAacBvekp59qFEXhmmaip8E8DB3VgsJu2MsPFWN8mSmszyOoJK2/O5CLEVlhKK/s4JUCLEtkz9RxqKDips/PrQsSzDQ19yw+CGmYI49ohHygdOtmz0GMukeETLjxwptalrRRNIoW84da2WKvOGebAD7Y1h23xyKhyWfNK2RB+Udpi6qj1cqIEt4gWIoMbpL8JdtrOiSjT1+1Yp9kkuSnMsVWeHJGaE8rELNVACZ8Kyx1odAaIhl+zCRGDPsdX3cTi3yBJ2rGj9M/3nuHY/PPPG5g8bVy3XDJW0ef+2RtQ80LELEMzd2g0tJIRtiOE/u8FPmpEbTwy6OEKhd5oWtfBAzrlxqL5tlGclYzJCKL4v+r9VrVzAFoMniCjdhjRlSf4632gOglJL3m+sEkVW50f7tNaOBhUCn44wSDS9Gz9c2YNtWpw/XqfDu166x10bTF6X44w2 nn1ci5Gr 36mXDaUSkUtg+YJpGVdTvA6HdGiEC6hL+iyuKGd1Ie304dHwwpn/cHDxNDb6zxZm+pIU2Xij20mipMLDakm/pDj/SimEk9CsrVBqFiQ0aHFoWJq6r8uR+psqLjiU1r8A8ehnyiYZI/4iLEtv57knoS4msxP62NcZnKoSaQXTeCoMbKnUyoDeBwzeY23aUBt9P6fiQrFYuqrFm8UhrumRThMkn2tKD1P20gnfnx0ng9GRDT3R4Dxc6fvAb2wcSTKpPKK7XUo5QqD2/oWpcmJTYmx7F4JeZK8mf0ghTVqcVT5OtKjh1dPE0SMSP1WJZyRADYT9gGMnGL8Y+QjNPBv3h3hLW/4dOF23n28WrdsKq/zDMrBOl5LVyikpoMscv+e2Crs2Y7r22bstxh0fT1eKE2y2H6/8gym9WWyJEg6/2g6bjdSggk1f480Uho+yaEgPs7QmtNEdnV674dbl3ggMefoPbSSI+dWatQALQxv9Sk19qIU5lxf7bggmbiaV/h0qSjUlwJYnwtCJpHz0zn4OvM1gj/SyQ+IgXjaaNcfkgZ8mw/7OKdHtIBXEms8eDEqCwwZUmzvcuRx4ePHAReWulha/r8RBU0RD4/Eg30ti1oPMTpriJMkGvSX6AqVO+xt3alusu/136CqGj2CE= 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463760895-168202884-1694832249=:16517 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE 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. >=20 > 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. >=20 > 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; >=20 > 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 discussions. Thanks, Hugh ---1463760895-168202884-1694832249=:16517--