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 9ABDCCE79AA for ; Tue, 19 Sep 2023 21:10:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1032D6B00D9; Tue, 19 Sep 2023 17:10:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B3D76B00DA; Tue, 19 Sep 2023 17:10:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBE086B00DB; Tue, 19 Sep 2023 17:09:59 -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 DE0C96B00D9 for ; Tue, 19 Sep 2023 17:09:59 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B34B41602E6 for ; Tue, 19 Sep 2023 21:09:59 +0000 (UTC) X-FDA: 81254589318.22.814B39E Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf11.hostedemail.com (Postfix) with ESMTP id C5F2940010 for ; Tue, 19 Sep 2023 21:09:56 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UCUh6lK5; spf=pass (imf11.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=shy828301@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=1695157796; 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=uvIEfiigHClNF0zDtmOt3K3WnUjsJmS7BEsVemoJ0UI=; b=WU2d6wUob5YF34ACUmAIFJVlT0GZ7inFhdEcjdTE0rbiZi4GyJsP80q5j4UDJnK7zr2T43 /w9RCOboDvyH/lT4tfGo0u1SfY/3jq2uTX0K2basVINhaTNQXOC+LQsPr8vpXHmvxaCYDc Bt/5vcIh9LE/rZdagFGVk2nLtYjgwXo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UCUh6lK5; spf=pass (imf11.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695157796; a=rsa-sha256; cv=none; b=F2SftVZofuohkjRXr9Ia9gKE6b72E5hsCDbbG3WbYUGODxvYGCgH59NQBNJ8+UHGIRcJnh GdDeqwYl72kBxDNtptp6fOUj5QD7ZfH+C7yul57D1g8H5+OuX0JSXIanQzkhheqeDmtKWa 1iLi0VDRPaNlOyAbOuMBpoMrxYc2W/g= Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2746889aa89so4248962a91.2 for ; Tue, 19 Sep 2023 14:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695157795; x=1695762595; 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=uvIEfiigHClNF0zDtmOt3K3WnUjsJmS7BEsVemoJ0UI=; b=UCUh6lK5NIRm+ADaxH111V6k7LoG1XCUdAIxSBysauy4fFfau79GfDZx3H6XRjjfmE l/o2lL777+KfcH9/zaEFaRTbGwY/q8FSG4YfPMabFVNtUjfVo3tnt5rrlNTFxtXrgNt8 eV+bfWLTTbuk3pwCk5oX6QcrhzhchEspCvx0SNZgICa6xpZmXQAx4rUAbzHYSsm1XVgd hPfEiq38xrFymzThZvzuFcB+s8Vaii286YtdIsAnGTjLfNOE8FYGbqwSaSPGdBCqOZgS Et+PBIyTC00nMeOfUj48rku8MLbD1xJ0D+mMzRWdndlNcm0XJpv4EkRw4+V3hSNqDUbW zbIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695157795; x=1695762595; 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=uvIEfiigHClNF0zDtmOt3K3WnUjsJmS7BEsVemoJ0UI=; b=ADc8IEe4zSPcRKcjtcRvtuYtVwOOc4x3shswo91JMGucGiJ3Z90aN0E6JIEf8BAaVa 9yrwT5T9W/+cjV2w117ZDY6tJJ9fdSF+Eq5+teqkerxrYKhSy5BCKhtsjJsIw5R1Htmw 5/EhEOnC2ETCd57m29l6poz3+XpCjiaDEhhc162WRMRr6PAX4CzThHxzOmWctCxaCnAX LH4oyFjQlA/dsXXGCJZIAoFKBwIwYRL1ghFjG28huGMafC+bfRBkCJVrcKf0zMtX6B9c 7Vb+Dbi14Ux+e+1tcwRhx000XfHpEiToNk9XxZ+GkUEraV4VyE65UlFXTiITo9Jwq//x sIAw== X-Gm-Message-State: AOJu0Yyjc5vSwHyLTX/FQcq9dy7Ak8YB0v9b91hQP2xZL9zg+QIGyPGF j2NC/4m2HxRwdHXkdT4MrsuaEIHFA4ByWWl6swA= X-Google-Smtp-Source: AGHT+IGNfJwxXxR2k0CiS0SuKc89Kp3NfhqIFIY69wej3IBe2VVWG4GgZ5VymqqXKmbW4lGu7cGc26mxi8sfUzErFKM= X-Received: by 2002:a17:90b:60f:b0:271:9237:a07f with SMTP id gb15-20020a17090b060f00b002719237a07fmr889618pjb.32.1695157795347; Tue, 19 Sep 2023 14:09:55 -0700 (PDT) MIME-Version: 1.0 References: <20230918211608.3580629-1-surenb@google.com> In-Reply-To: From: Yang Shi Date: Tue, 19 Sep 2023 14:09:43 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: lock VMAs skipped by a failed queue_pages_range() To: Michal Hocko Cc: Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, hughd@google.com, vbabka@suse.cz, syzkaller-bugs@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+b591856e0f0139f83023@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C5F2940010 X-Rspam-User: X-Stat-Signature: ays5yjeb65ebt98ma77emyj1y1a7botq X-Rspamd-Server: rspam01 X-HE-Tag: 1695157796-85658 X-HE-Meta: U2FsdGVkX1+Cl1mYgo9pjpudhG92inV4Jmafzr3Le/orrROHh5ciOsSpNd7gEN5VsnMSIhEFymI2pYzNoMFsiaFy948cioys4UkfH69dmDy8u9kFsBByx36elDC7+5giQTylpjrPOkWnkTzi7SmHNXahYk1Kq3NOrFpE4tUx8xlzY9jSPAlZa/lFZ8UMKTN8ZJ2+mFWkqCUTKJ9KjqZTVZjlm8QsxNgUL3H8P6xCBEYNWCUUVKgVuHCKxugYyXURaZweHg8CnoNa+7txW97frtRs6h+J/CtJ5352ohSt3VVVo3nbrl41RB+I55WsQ/xrBBM0XkF3pNqrmOg+DaxmNOF6lf7RmmDYQnWQ9q67ov1A2mYGbTOf/gAi+GqKJiwyvFgLnKG2JxPt1ewYdF4tZhZ3moalNdkanl8AeE54kdQ9doTTXqkr6e4WpO/ErPY+MyvWhOLtwzpiP7kQcbYBeqiXb7Pn/sDx7mGhlEE9LclJzRPuF0+LWxsBL9BpLNlCWHEEvLmL92C6aPT6G+jrK3UvjUQJx5EtQw8c3TkU3PFf4xjl+7VUpCy4VnPVV/gVDf03vI0kOVStscxikio3p0FgDHFKmM1MRMmK9FgecheTNZrTP83ViVAs5MKwGsLciLAAk5miHdxJwbGhPWcEtKiolhXvGAGeCSNdKjn8niQ9cjyHYUddf7UY7X7GHhWCNgTNvaMrOFDmpbqSdytgST2b5IQWp0aezCSfElIZPbcuC+uq5SVi19BGF0t3UMpOaZUUP6fl3zQ2ZGrdOC5RavhyGMcXW/zhRyPts4WVUYYv5RpWzY4TiH6fdRoODs8CJ9wErLDu5FIT3ofwX92kRNRFsnJgpQ6m2pFrdxwnx0y8pEUi2+KdKG6odijMEq5vYg2VYEKm6+hUDdlAsj3OfYXYFI2vvIgB2GeTY4JVNh8+vmqQGJXuz4nfP91vqHVRVZ8da61hq/yIZ98fPaN 9yC60RCB 17a59CEXBnCKUFrFGq8wVEkaDXaaF5BHEUyayyvoGcrpH18r0K1yxGHwIXY8m03rr4GA3TdY2mwdU2BojUHq6JR6EmFsUIrq5qkYUbDYPiNhUHznfBtdxSvyykGeS2DDSaVBJAqOv4EvmeQqfHsiKKFMBoUh8IVEQmKYoSgdI/OV8hA+x1LJL8FLOJM2TX9xy8VQu1YdbR0zV89/3k1Qx/6RyDV7P10VIpKIeJ9aneH/wY1fHHWgTBlcTqW5+qNLyHZ9vfs7glH9Ye2EEFKJJ3hfwvwtV+uYYJMTm/r1BeVZgAHLZTv3ZiO025D9RaxTukJURvMJmBB8UNa3st8Al5fNRIHLuV5Ykr8SNhfn8HR4rdEk45JTxLjAtuRdl3Yge7TuYBhGoys6bwV80Ek08qz/y6umlwlEb+E0VzEzc5Ra7kG/O6dC19gkTs3+WZFIuSbNDqvfEFD8i96MdbPHbR8zM6qKcIgG2z8T+fcuplFm2+HScRira0fCSPHxJEtZPKpUqEd7fRIKzfrMkr3ZACSOQN9aFqdAWDjKrdRP0jgmCq6uge5G2tXT9+IE936zXyDkjbHrRlsNO0dZd0WoMbXNRFQB5s/8aDLekFGsD1mRWs783JfcHpY0ybQmM1KTLb7QhYBg4aX5kxpk1Gy9mczAL1ILHHoAA0JKU2pOHtXdMNn3SG/f0gtH7Cm3d4ElHw0UApvNLMgeyLfzeXtpjcu8dlQ== 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, Sep 19, 2023 at 1:53=E2=80=AFAM Michal Hocko wrot= e: > > On Mon 18-09-23 14:16:08, Suren Baghdasaryan wrote: > > When queue_pages_range() encounters an unmovable page, it terminates > > its page walk. This walk, among other things, locks the VMAs in the ran= ge. > > This termination might result in some VMAs being left unlock after > > queue_pages_range() completes. Since do_mbind() continues to operate on > > these VMAs despite the failure from queue_pages_range(), it will encoun= ter > > an unlocked VMA. > > This mbind() behavior has been modified several times before and might > > need some changes to either finish the page walk even in the presence > > of unmovable pages or to error out immediately after the failure to > > queue_pages_range(). However that requires more discussions, so to > > fix the immediate issue, explicitly lock the VMAs in the range if > > queue_pages_range() failed. The added condition does not save much > > but is added for documentation purposes to understand when this extra > > locking is needed. > > The semantic of the walk in this case is really clear as mud. I was > trying to reconstruct the whole picture and it really hurts... Then I > found http://lkml.kernel.org/r/CAHbLzkrmTaqBRmHVdE2kyW57Uoghqd_E+jAXC9cB5= ofkhL-uvw@mail.gmail.com > and that helped a lot. Let's keep it a reference at least in the email > thread here for future. FYI, I'm working on a fix for the regression mentioned in that series, and Hugh has some clean up and enhancement for that too. > > > Fixes: 49b0638502da ("mm: enable page walking API to lock vmas during t= he walk") > > Reported-by: syzbot+b591856e0f0139f83023@syzkaller.appspotmail.com > > Closes: https://lore.kernel.org/all/000000000000f392a60604a65085@google= .com/ > > Signed-off-by: Suren Baghdasaryan > > I cannot say I like the patch (it looks like a potential double locking > unless you realize this lock is special) but considering this might be ju= st > temporal I do not mind. > > Acked-by: Michal Hocko > > Thanks! > > > --- > > mm/mempolicy.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > 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, unsigne= d 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; > > -- > > 2.42.0.459.ge4e396fd5e-goog > > -- > Michal Hocko > SUSE Labs