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 829D0C433F5 for ; Tue, 8 Mar 2022 21:32:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 044A28D0002; Tue, 8 Mar 2022 16:32:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F0F988D0001; Tue, 8 Mar 2022 16:32:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D89568D0002; Tue, 8 Mar 2022 16:32:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id C78E88D0001 for ; Tue, 8 Mar 2022 16:32:34 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 83E961823E411 for ; Tue, 8 Mar 2022 21:32:34 +0000 (UTC) X-FDA: 79222518228.27.20029BD Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf17.hostedemail.com (Postfix) with ESMTP id E52B74000D for ; Tue, 8 Mar 2022 21:32:33 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id kk16so513767qvb.5 for ; Tue, 08 Mar 2022 13:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=YOXQDRCIfx4IjSjbZnhb2Qm6e7avo35Rozd5Ovb9UuU=; b=NoBZj+BoD+zd71XjiH9cllPdclP0sfXsbHf7r1D4BvJDBNwDI0a/sBSL+5vDPbAh7H P7cOhmDzcFMJEGXIgN1TyoI7iPCBa/Z4lO624dihHnRo1DxTSWTpZ6f2dspqZoLqUyEk ZXn88TzOQJd1Bp2ZLDV0TkHHPy1k9/jqm21rehJ8fXk1S8Ic5qqHbFQvgJCzrZxEWp13 qMC9Ml13fL8fdHLCpwA0j64jjXEy4AnPKWPwrFjIcLSTshY9MvNitHgYECpzdegD/6xR 0ArGZYFsJDf5z1XnWpkquNXwVej4RrPiGF/ZbiK7/k2w9hljUCpDBjKe+ok5h0jFPIHS X0pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=YOXQDRCIfx4IjSjbZnhb2Qm6e7avo35Rozd5Ovb9UuU=; b=PrMtAWZ9UweGJZlWFoUN+JuHk+5Fnn1T2ayecgeC/sj4Rf3cWKHtum455Cj/1EDS1e r5OlZsgA4R8fZ+DHLA4najLXSv24ZAKnN+wWO8iBWwG/N/w2TDR47OLW/af/DEuOK3ss ds4kqOekqhme862bQLEwjFRfOHicRQVrfVmS+FY/zcaZbZg0Iba78qzavHKQ15kQtG3j rOS2II3D3HUuU+ak2VL6FMRJeRl7ykpMRnH9NQWMHROXxhxWijl3rKBT8JOBT9nDNckc BrA/VCmcEenEm9AGT/W6/Wp2YuZOf65+zIj+ryxcAVm5bSrJoW5yJ9EyJQJ3BwTHlz5O MozA== X-Gm-Message-State: AOAM530jn6lUblaFf8IkneGOgwwssTH5ZwPWlAb6Adz7oxjQzplO1PAh jVBw+i3FCN0VSM78qB8RoKJLCA== X-Google-Smtp-Source: ABdhPJzl0aw6y1OP+W+9Ro/QjkGXpfNxhZvFkO4SJY8YmozH4S0Iqlsyp3KV2dzqvdSK3w1UuzMc9g== X-Received: by 2002:ad4:5f49:0:b0:435:a88e:ae0e with SMTP id p9-20020ad45f49000000b00435a88eae0emr5221716qvg.98.1646775152887; Tue, 08 Mar 2022 13:32:32 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id h17-20020ac85e11000000b002ddd5fab777sm77992qtx.41.2022.03.08.13.32.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 13:32:32 -0800 (PST) Date: Tue, 8 Mar 2022 13:32:18 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Liam Howlett cc: Hugh Dickins , Andrew Morton , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH mmotm] mempolicy: mbind_range() set_policy() after vma_merge() In-Reply-To: <20220308160552.d3dlcaclkqnlkzzj@revolver> Message-ID: <6036627b-6110-cc58-ca1-a6f736553dd@google.com> References: <319e4db9-64ae-4bca-92f0-ade85d342ff@google.com> <20220304184927.vkq6ewn6uqtcesma@revolver> <20220304190531.6giqbnnaka4xhovx@revolver> <6038ebc2-bc88-497d-a3f3-5936726fb023@google.com> <20220305020021.qmwg5dkham4lyz6v@revolver> <29eac73-4f94-1688-3834-8bd6687a18@google.com> <20220308160552.d3dlcaclkqnlkzzj@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: E52B74000D X-Stat-Signature: fxg9q5ewtrj51i36dzgjboni9uiq7oh9 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NoBZj+Bo; spf=pass (imf17.hostedemail.com: domain of hughd@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646775153-346083 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, 8 Mar 2022, Liam Howlett wrote: > * Hugh Dickins [220304 21:29]: > > On Sat, 5 Mar 2022, Liam Howlett wrote: > > > * Hugh Dickins [220304 17:48]: > > > > On Fri, 4 Mar 2022, Liam Howlett wrote: > > > > > * Liam R. Howlett [220304 13:49]: > > > > > > * Hugh Dickins [220303 23:36]: > > > > > > > > > > I just thought of something after my initial email > > > > > > > > > > How does the ->set_policy() requirement on tmpfs play out for the > > > > > mpol_equal() check earlier in that for loop? > > > > > > > > It took me a while to page all this back in (and remind myself of > > > > what is case 8) to answer that question! > > > > > > > > The answer is that the mpol_equal() check at the top of the loop is on > > > > an existing, unmodified vma; so it's right to assume that any necessary > > > > set_policy() has already been done. > > > > > > > > Whereas the mpol_equal() check being removed in this patch, is being > > > > done on a vma which may have just been extended to cover a greater range: > > > > so although the relevant set_policy() may have already been done on a part > > > > of its range, there is now another part which needs the policy applied. > > > > > > Doesn't the policy get checked during vma_merge()? Specifically the > > > mpol_equal(policy, vma_policy(next)) check? > > > > Sorry, I'm reduced to the unhelpful reply of "Yes. So?" > > > > If vma_merge() finds that vma's new_pol allows it to be merged with prev, > > that still requires mbind_range() (or its call to vma_replace_policy()) > > to set_policy() on prev (now assigned to vma), to apply that new_pol to > > the extension of prev - vma_merge() would have checked mpol_equal(), > > but would not have done the set_policy(). > > I must be missing something. If mpol_equal() isn't sufficient to ensure > we don't need to set_policy(), then why are the other vma_merge() cases > okay - such as madvise_update_vma() and mlock_fixup()? Won't the mem > policy change in the same way in these cases? mlock provides a good example to compare. Mlocking pages is the business of mlock(), and mlock_fixup() needs to attend to mm->locked_vm, and calling something to mark as PageMlocked those pages already in the area now covered by mlock. But it doesn't need to worry about set_policy(), that's not its business, and is unaffected by mlock changes (though merging of vmas needs mpol_equal() to check that policy is the same, and merging and splitting of vmas need to maintain the refcount of the shared policy if any). Whereas NUMA mempolicy is the business of mbind(), and mbind_range() needs to attend to vma->vm_policy, and if it's a mapping of something supporting a shared set_policy(), call that to establish the new range on the object mapped. But it doesn't need to worry about mm->locked_vm or whether pages are Mlocked, that's not its business, and is unaffected by mbind changes (though merging of vmas needs to check VM_LOCKED among other flags to check that they are the same before it can merge). Does that help? Hugh