Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     Hugh Dickins <hughd@google.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH mmotm] mempolicy: mbind_range() set_policy() after
 vma_merge()
Thread-Topic: [PATCH mmotm] mempolicy: mbind_range() set_policy() after
 vma_merge()
Thread-Index: AQHYL4FzWFkyFnZUSku+xBH1UQyT+KyvkiKAgAAEfoCAAD4yAIAANciAgAAH1YCABZtSAA==
Date:   Tue, 8 Mar 2022 16:05:58 +0000
Message-ID: <20220308160552.d3dlcaclkqnlkzzj@revolver>
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>
In-Reply-To: <29eac73-4f94-1688-3834-8bd6687a18@google.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?jLDRpf4wak5G3Eq4Pz9kRR/k3ebDjl3uvebqQZbRNU1EWLfOt+lPwvxAJvxe?=
 =?us-ascii?Q?fi4CGvQRvN+/3UJaGN+p4GiDkRGPlNeEddlk1KzK9Qv+CsigfZanNueCD9Qz?=
 =?us-ascii?Q?UhXPShvabQtiPeWnosaNtVJxlen4amst5EbV+UbVzLhCU7xG5n7rpT0XlLHr?=
 =?us-ascii?Q?4mUJIPFE3fORXrSgkp3te5EZy0Qa6+bsK7JcNprv95ElmhBgv0QyqW8keG54?=
 =?us-ascii?Q?ZXXatDssWgYHXAuoGWNyYORdzoe0SWfQ7Ijd/PIyRKrgp1dwRQ0Uv/a06vpF?=
 =?us-ascii?Q?cM0PPfJskGKCEXni03PP40RX7VFQmRlQVf8UaRQBLlCXuRpaBpL+FkqJjcfn?=
 =?us-ascii?Q?hHgRhceZRtVodcO38w+V5aPl0HEVR6d/tw0SH2VWFl+1qY39Dr+i9QSQzq7o?=
 =?us-ascii?Q?txHie71s3Ve/9OXupNDsDrD2+Jy4v2F4U6rHOiJeCb1+HtXGGyfXGkGQBjt8?=
 =?us-ascii?Q?SQE9P6DNQhKNoE8EqqGCkkQ8Jer04ao6J0K1m9zYan23IfqynXjJmwnwkj+P?=
 =?us-ascii?Q?kmtMqOg2VwwT5bkNB4f9kzRTvm+wrTPUVLQ+86hP7wvKs5yPPRiSLMKMml/v?=
 =?us-ascii?Q?VisC6eQHTll8lrnHbhcsBzpIbs4OJ+tYgZJH3qYHkXT4qOqfv1Cvctq/ml2E?=
 =?us-ascii?Q?ag0rMxq/wvUKfXfELGWk9LrAgfviHLQIbsCiMSYFt8OtL1TJRotuTaTncPpb?=
 =?us-ascii?Q?89UTjr1OAmrdCquRKjEIOnmFgJn3vQbWynzv0xPYDudeWxrKnI0lWOU1Asra?=
 =?us-ascii?Q?BCHjYbDAIa+lZkKf6oJdHKumNPUUOzzKkGKcFEfu+SojwgopC8mpY5jwlv5z?=
 =?us-ascii?Q?3AnVVuBaqcfkNh4tJqEgGWwdlJb74vP2/sLRfrO971mX/pQATj+5DvRHXHEi?=
 =?us-ascii?Q?FlWhuZd7D70iF84/cVBDVXuG1l6iBT7FsPgzYXd+Ak+ZgvceL4VHNpCwT6NH?=
 =?us-ascii?Q?SrHWdMFlcv9OkrYR7R4mxLnmslpd1vqEaEq0rf3Zgu1m9pbsAB2nF11lJ7BD?=
 =?us-ascii?Q?+wDHXzCvQOZvO1EtaudFdJYSTZb4yHrJ/X2k2QXFj5NiUDDfkHg0RTDVE+Ys?=
 =?us-ascii?Q?yMjxSYUWUjkZ78m6OosEdKKAyQsjcYJqfrOKG6Fzdzh8X/e8qflRq5Qb0wfN?=
 =?us-ascii?Q?l4RcBETBVDBwGHbbsVZQlD2Q1S5s14gxv1ZlSQgX+oWSEsv4FW6954NX8j7w?=
 =?us-ascii?Q?n/TSBkB+zWJMJ7PPsQ5YWkKk6MvSGlJxkvhC4QZ09jKAGg+36NZaS8ICxJeF?=
 =?us-ascii?Q?43t30f9VQIa+ALZN19FQfhk9HbQm/d4grvCO2fExWhTpQhlxUfwUworLrlCS?=
 =?us-ascii?Q?XXqvRscaka2wgXQzHgsqWRV8jUNDX4drt7Ly4BOFmq35QOvZbSCJC/iNwQf0?=
 =?us-ascii?Q?JNKIAuilnuSPzvPu4aNVc4KW35N6TDJdQFZM+aZhTlsexyDqrntPQOwyBAUG?=
 =?us-ascii?Q?ZOB8CS2uqeBYvNKb55mEs8Sr4K2qARlI0iethgoswfeVGqqs5qzimDXxUkaj?=
 =?us-ascii?Q?GMjHv6c329ygX3H4Mg7tI0n4a7UyqmXg4s0OcPaP563BBwEBNoBA33diVzzv?=
 =?us-ascii?Q?OxsY8aK3/UphlGMk00yt1wIVs8iYBbtB/lcss4kLzE4Jeut0k3MaZ49y+um3?=
 =?us-ascii?Q?ZhIOC1gfgU3RYM8STcAOiGQ=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2517C979A809384AB2F27ACB982B5EF2@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5159c080-0626-457b-87dd-08da011d88ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2022 16:05:58.9223
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NFAMjxZhc3KAKBt/gB+FFpNmfSEOxkX7zMt11pWZQS8K24fbDJxtgZ9ZsMMWoy6egBHRM4VH4KKhFPseWgOadA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR10MB1513
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10280 signatures=690848
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=822 bulkscore=0
 phishscore=0 malwarescore=0 suspectscore=0 mlxscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2203080086
X-Proofpoint-ORIG-GUID: CJE6nYl3hX8Pf26gg33HY6D7K7aNEnK6
X-Proofpoint-GUID: CJE6nYl3hX8Pf26gg33HY6D7K7aNEnK6
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* Hugh Dickins <hughd@google.com> [220304 21:29]:
> On Sat, 5 Mar 2022, Liam Howlett wrote:
> > * Hugh Dickins <hughd@google.com> [220304 17:48]:
> > > On Fri, 4 Mar 2022, Liam Howlett wrote:
> > > > * Liam R. Howlett <Liam.Howlett@Oracle.com> [220304 13:49]:
> > > > > * Hugh Dickins <hughd@google.com> [220303 23:36]:
> > > >=20
> > > > I just thought of something after my initial email
> > > >=20
> > > > How does the ->set_policy() requirement on tmpfs play out for the
> > > > mpol_equal() check earlier in that for loop?
> > >=20
> > > It took me a while to page all this back in (and remind myself of
> > > what is case 8) to answer that question!
> > >=20
> > > The answer is that the mpol_equal() check at the top of the loop is o=
n
> > > an existing, unmodified vma; so it's right to assume that any necessa=
ry
> > > set_policy() has already been done.
> > >=20
> > > 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 ra=
nge:
> > > 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 applie=
d.
> >=20
> > Doesn't the policy get checked during vma_merge()?  Specifically the
> > mpol_equal(policy, vma_policy(next)) check?
>=20
> Sorry, I'm reduced to the unhelpful reply of "Yes. So?"
>=20
> 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?

Thanks,
Liam