Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp639357pxb; Tue, 5 Apr 2022 16:56:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCxANXHiKvBReuAMrQhaFlaNDGIV3Fu48SID6Ym1LJj2iU1/v+sMjoD9v3Uyxxo8AvCSi6 X-Received: by 2002:aa7:90d4:0:b0:4fd:acb9:8eac with SMTP id k20-20020aa790d4000000b004fdacb98eacmr6222730pfk.24.1649202975111; Tue, 05 Apr 2022 16:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649202975; cv=none; d=google.com; s=arc-20160816; b=t3q+JS8TKm+XSTfZjFHVyoz2270GU7Fk8Jt0NRFtFy3l8BUG/Pc/N7TrBgdJd5xsCh cHyq6Kd9PDxeEHRp0BZrVYD8cVle8LvingS6/siWWsDAgXyULxKYBaSCtLE2aM2tC0OE PRQCPfzY/5InnOvS7xZWdDg5hWh9ezdPexxz8x8sGEFp4UfhDaXmkt0iy2yVcHO8ZPPS RULw5frfuqcw6TIRo05C65I/XfWtypcu5ivqmWu6Fo2a+lyGLH9eAKfTOPKaN2bSslM5 l3GhDkdBtiCi86GkWzx1Ol4QZMQVOAUH0J2BEE8mfSYrt8Rsw2etLiZytGVwUIyOqDeR e6GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=UhKSUx7NX9nDTvctSg6bHVQIyIEyp0j9l2viM+RiltM=; b=FJP/lrHhuBUHfEdMfrXzUHdPuXAgx2JlqyTtEVPAhjzPcNoeGAVPWYqE5rYaMNGBf0 ZshpXdr9fyJHUv3iuobYPFhCwwL2H/yM0pGCR47TfLkSvduXLD39UfdtHs4iKehBn3Fw alpLTvmgpoaziNYRg3Ewy2Imt5/HrYWSuzjpDyQ0xQlS9xNr49zcQvXJyKVxmcwnDKs7 QymS6LjY0dVj8Kx2TnST1vOoUf9nsPdzevFgJrv8qV4oITOtCabBgs7eMBmTMbE9zpJQ 7L5qHwLfXZu1zBRojt4Ms63tMn8fG2SHETMPdn49xP/8UfkZQkc22mhtMEI2+qmbjCzT G4yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=EMvHHRE7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id np17-20020a17090b4c5100b001c9ef94cebesi3957153pjb.134.2022.04.05.16.56.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 16:56:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=EMvHHRE7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C35B8276F99; Tue, 5 Apr 2022 16:41:48 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1387449AbiDEOcN (ORCPT + 99 others); Tue, 5 Apr 2022 10:32:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240394AbiDEJeU (ORCPT ); Tue, 5 Apr 2022 05:34:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A2118301C; Tue, 5 Apr 2022 02:23:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DAD0A61659; Tue, 5 Apr 2022 09:23:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5999C385A4; Tue, 5 Apr 2022 09:23:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649150629; bh=1DgkdNFO6r6H+hSygsx8JZmtOvDEknQ6vZRdHvFtBQA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EMvHHRE7cxFpc5KPlJGV2jewguDgDAthR0fM13EsZkQ7C873TmMO1Xm3dGdcQuVFg ckH0jeBFNe5Q+24jfl2808RdiVr3lkp1RD5Zx1l0Z7/FzfrqeAqMmzKOd1FppPF7sI 1RKu8dlouGmD83/M0DmV3MPwNaN614e1KhYDqh50= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hugh Dickins , Oleg Nesterov , "Liam R. Howlett" , Vlastimil Babka , Andrew Morton , Linus Torvalds Subject: [PATCH 5.15 086/913] mempolicy: mbind_range() set_policy() after vma_merge() Date: Tue, 5 Apr 2022 09:19:08 +0200 Message-Id: <20220405070342.400563491@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hugh Dickins commit 4e0906008cdb56381638aa17d9c32734eae6d37a upstream. v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem") introduced vma_merge() to mbind_range(); but unlike madvise, mlock and mprotect, it put a "continue" to next vma where its precedents go to update flags on current vma before advancing: that left vma with the wrong setting in the infamous vma_merge() case 8. v3.10 commit 1444f92c8498 ("mm: merging memory blocks resets mempolicy") tried to fix that in vma_adjust(), without fully understanding the issue. v3.11 commit 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() interaction") reverted that, and went about the fix in the right way, but chose to optimize out an unnecessary mpol_dup() with a prior mpol_equal() test. But on tmpfs, that also pessimized out the vital call to its ->set_policy(), leaving the new mbind unenforced. The user visible effect was that the pages got allocated on the local node (happened to be 0), after the mbind() caller had specifically asked for them to be allocated on node 1. There was not any page migration involved in the case reported: the pages simply got allocated on the wrong node. Just delete that optimization now (though it could be made conditional on vma not having a set_policy). Also remove the "next" variable: it turned out to be blameless, but also pointless. Link: https://lkml.kernel.org/r/319e4db9-64ae-4bca-92f0-ade85d342ff@google.com Fixes: 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() interaction") Signed-off-by: Hugh Dickins Acked-by: Oleg Nesterov Reviewed-by: Liam R. Howlett Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/mempolicy.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -783,7 +783,6 @@ static int vma_replace_policy(struct vm_ static int mbind_range(struct mm_struct *mm, unsigned long start, unsigned long end, struct mempolicy *new_pol) { - struct vm_area_struct *next; struct vm_area_struct *prev; struct vm_area_struct *vma; int err = 0; @@ -798,8 +797,7 @@ static int mbind_range(struct mm_struct if (start > vma->vm_start) prev = vma; - for (; vma && vma->vm_start < end; prev = vma, vma = next) { - next = vma->vm_next; + for (; vma && vma->vm_start < end; prev = vma, vma = vma->vm_next) { vmstart = max(start, vma->vm_start); vmend = min(end, vma->vm_end); @@ -813,10 +811,6 @@ static int mbind_range(struct mm_struct new_pol, vma->vm_userfaultfd_ctx); if (prev) { vma = prev; - next = vma->vm_next; - if (mpol_equal(vma_policy(vma), new_pol)) - continue; - /* vma_merge() joined vma && vma->next, case 8 */ goto replace; } if (vma->vm_start != vmstart) {