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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6F8CCD37B1 for ; Sat, 16 Sep 2023 02:55:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235974AbjIPCyp (ORCPT ); Fri, 15 Sep 2023 22:54:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231539AbjIPCyZ (ORCPT ); Fri, 15 Sep 2023 22:54:25 -0400 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19C9A1BD2 for ; Fri, 15 Sep 2023 19:54:20 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-59c26aa19b7so7637437b3.2 for ; Fri, 15 Sep 2023 19:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694832859; x=1695437659; darn=vger.kernel.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=pRgYEKeBnhc137LJPUJ1YX5jXl/+dvV/D/bsE7EFVFU=; b=ruaSHKEQKnnwpWuTTIeLxtcg3C4ijVzzFj7/rAGJGT6xzsobYUlPuZ5VsLKvi1TqWI zPPjMa+kR0HW9p3PtE/1eH5MgXgFt0n/GLJh6s3EuOgtqmejdKZPHnYwNXrpwBK3Sw6P uPRlb0c+eQUMgrrEUODBgD8KW6yGMI2YTXBcRrZuxmVWFSwSEeTta4mSoX8jF0oQF2TV EzT6/xQ/v5/0BjCS1loytBSf6AnzcE4NRezshCbhgrP5QPcROsXwIx4IRg2YbjObfrvo G7EZLtb6F62FUdJnWb34U54AR6mAaL00itz3wv9OIp+ba8GVQS2VqSRtoZ+8HtIoGX4N C76A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694832859; x=1695437659; 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=pRgYEKeBnhc137LJPUJ1YX5jXl/+dvV/D/bsE7EFVFU=; b=LF+0vynr1NIVj9ReBwT3oFnYTDmVK9ii6olUTOEBQK79G77T9kj0SAbjREEDAIpmF6 HWC7RBpL7VLXGNfXwT3sYR20BFWb92POQrmM0pU0fWKd0xMmfO6tU0L+kUxC40W06VkY uwvcjj8NbZUy+xkYENXZwYclEB05rYYqjGakmW6Q8ufPmD6jMuE3/jaBtl1qB0jQeyY7 4O9DeQJ898Ah9i6R+5+7RfdeBcCJN+bi3TOaL+PKA937maeHP8tTQ9tnl1ejT+2A5dVT 2fFpWHZ4POLG8cfIOAQ0t2mzdCI1MM9Ju9EQx7oDO0L9Hn8aXmOT5F+ZE8dWkaOlI1BH naqA== X-Gm-Message-State: AOJu0Yw81nhUbkBBPZmP1dcJ/T84TMmx2rgW/JvJwQBjAuDq79gX/eyP TS/mEU9N5fftKIHHms4Sh93TWA== X-Google-Smtp-Source: AGHT+IGyKMGHnMEM0WFtSTclUrFRubYqjyVdCHiMGPhbY5XPEn9cF7hIB744pXwvKTtzMGrN/Y+6mQ== X-Received: by 2002:a81:73d5:0:b0:59c:3f8:b0ab with SMTP id o204-20020a8173d5000000b0059c03f8b0abmr4202510ywc.41.1694832859109; Fri, 15 Sep 2023 19:54:19 -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 u127-20020a0dd285000000b0059bce30a498sm1196082ywd.139.2023.09.15.19.54.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 19:54:18 -0700 (PDT) Date: Fri, 15 Sep 2023 19:54:16 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Matthew Wilcox cc: Hugh Dickins , Suren Baghdasaryan , 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: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Sep 2023, Matthew Wilcox wrote: > On Thu, Sep 14, 2023 at 09:26:15PM -0700, Hugh Dickins wrote: > > On Thu, 14 Sep 2023, Suren Baghdasaryan wrote: > > > Yes, I just finished running the reproducer on both upstream and > > > linux-next builds listed in > > > https://syzkaller.appspot.com/bug?extid=b591856e0f0139f83023 and the > > > problem does not happen anymore. > > > I'm fine with your suggestion too, just wanted to point out it would > > > introduce change in the behavior. Let me know how you want to proceed. > > > > Well done, identifying the mysterious cause of this problem: > > I'm glad to hear that you've now verified that hypothesis. > > > > You're right, it would be a regression to follow Matthew's suggestion. > > > > Traditionally, modulo bugs and inconsistencies, the queue_pages_range() > > phase of do_mbind() has done the best it can, gathering all the pages it > > can that need migration, even if some were missed; and proceeds to do the > > mbind_range() phase if there was nothing "seriously" wrong (a gap causing > > -EFAULT). Then at the end, if MPOL_MF_STRICT was set, and not all the > > pages could be migrated (or MOVE was not specified and not all pages > > were well placed), it returns -EIO rather than 0 to inform the caller > > that not all could be done. > > > > There have been numerous tweaks, but I think most importantly > > 5.3's d883544515aa ("mm: mempolicy: make the behavior consistent when > > MPOL_MF_MOVE* and MPOL_MF_STRICT were specified") added those "return 1"s > > which stop the pagewalk early. In my opinion, not an improvement - makes > > it harder to get mbind() to do the best job it can (or is it justified as > > what you're asking for if you say STRICT?). > > I suspect you agree that it's inconsistent to stop early. Userspace > doesn't know at which point we found an unmovable page, so it can't behave > rationally. Perhaps we should remove the 'early stop' and attempt to > migrate every page in the range, whether it's before or after the first > unmovable page? Yes, that's what I was arguing for, and how it was done in olden days. Though (after Yang Shi's following comments, and looking back at my last attempted patch here) I may disagree with myself about the right behavior in the MPOL_MF_STRICT case. Hugh