Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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+KyvkiKAgAAEfoCAAD4yAIAANciA
Date:   Sat, 5 Mar 2022 02:00:39 +0000
Message-ID: <20220305020021.qmwg5dkham4lyz6v@revolver>
References: <319e4db9-64ae-4bca-92f0-ade85d342ff@google.com>
 <20220304184927.vkq6ewn6uqtcesma@revolver>
 <20220304190531.6giqbnnaka4xhovx@revolver>
 <6038ebc2-bc88-497d-a3f3-5936726fb023@google.com>
In-Reply-To: <6038ebc2-bc88-497d-a3f3-5936726fb023@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?bExTQ/WTkl6158u2AaUiuTcAJBGdWhh1COtjjaS3epmQQKpB5Vy3oc/leX4p?=
 =?us-ascii?Q?yl/e3dt4N5NzT+80k7Mh+nf2R7Hz4byCRlpdDE0q7rzrkJtTyPxiNcdJ3uw3?=
 =?us-ascii?Q?TvprGGwS+nt98XILyCmQh788G9WckHnfuEfdFJqwvuPbH8MWdG7t/vxcHVWY?=
 =?us-ascii?Q?uuqfdHlhGXfxseRhdlUH14WQ9X1WVXDfX0G092tP5g7xCknPXyw9x6fWkLx8?=
 =?us-ascii?Q?UDkLrhg9qCuPohH/6CQ/k6utkYA6kXvDQSgcqXHWyhcs16ToictSQ7C+/8Sr?=
 =?us-ascii?Q?MFXx4eGx9RqbksZ4P9D1ZswywR0rX7a5cxyX/ADFcWf82t69vIfZqG+RjdKc?=
 =?us-ascii?Q?8Jfl11BVgr3SnseBzdfAj+4C6Hqp6+QfShphlJeA9YRDLBK+9zs+0kdrT3Py?=
 =?us-ascii?Q?Sypa67YYVxLXamcVEt8qlHSLxZ9/ZzEFoCWYZshrp3vTKdPC5e3FRiGfQrqx?=
 =?us-ascii?Q?tvOkk7i7e4t8G1tRudmkLeZ+bL5X6sdiABplIt1OUT/ZaoWoTmFF9VpdUQ6T?=
 =?us-ascii?Q?Zst2C+IziT/ZGXdCKdaS2/ptR2XVfZ/Ne63l5a4jyFj4TXEcNfEnya5cpdTP?=
 =?us-ascii?Q?W1ENJvwbRoNg1pXD6NM+Vo/5QfkReg6jkOgv0kViwsVilSmuwEgtjmyUayin?=
 =?us-ascii?Q?VAGyMCce8mU2CLvKAPy7YHT/W8cHg8UJ1wjqJ6DJi+h65YHdsZbW79r2Q7/u?=
 =?us-ascii?Q?EaVAfoKj4owUiQdV2tBhLzLYzCM5JCzvptWERSPPR7onMXVb9V4K09vcHKbe?=
 =?us-ascii?Q?kOvDWfqYrIJEC1ikVV34VXvFnrMQuAO/6g7X3iBMTWmwt9Iqua2Cs0vdWkJV?=
 =?us-ascii?Q?qKd/UAVBV9W1mV4W9dCQoGUhctCUM7DMqH7suK5bo7HPq/yDqCQFea6lx0z8?=
 =?us-ascii?Q?Td+hdY/ho0iWArwcrdckb60DomiA6GmVUZ2iMqRu7vjrgS/x1PyXp7LlVGGr?=
 =?us-ascii?Q?SPWoRy2M6yCssTEFFmduODXQfkaGewIaym0o72BbcrLr3niMA3hpDy+yqOrI?=
 =?us-ascii?Q?0xwnLA6GNu0eijZ5gtyuH3Q+ZdLW25yhfV1K1nGPZkDuXRBq9KLn5aJz2Btx?=
 =?us-ascii?Q?ObYuGYafEiSMxPFQh5nruaifv++IeokHfA5cjU+AMqV3L36itRjqcFo00Nz6?=
 =?us-ascii?Q?IwDtoC+usNnRyawQtVwOFzD3qcpKqoAyIgiJE0GY5WW9DAqxVKBn0jCHwRNI?=
 =?us-ascii?Q?oRKPSWx9lC68UNq5dEHeUPav7lftmVVBNis5Zt7eHoV3SEJieQtSn+C2mBfT?=
 =?us-ascii?Q?QS35DIH6+1P/oZl46tXeGOURUmzGt/1lx3LFkWDsK5c7XnxL6A5EBq8N7SB6?=
 =?us-ascii?Q?aMez1kH7L4ER6aWGhYm36CM2qR4dn10lSei6y7UbUAWYVzSKJgyFJ2mjaH+V?=
 =?us-ascii?Q?AleabN8/P8BOpeggFod5Bco0oAQ2w7rLQPBCnW6lNUMmDdHhbdX/nn5Q0Xwn?=
 =?us-ascii?Q?iU6OIRYsoOBRgB/wF6R6s+oZbiUnn7Qe1gCkZ8gN+Q/uW/Btk01RhC5hGquy?=
 =?us-ascii?Q?PQHQF++WHIskLo18HlN1n/Phlx1YUtc/mAsvH7ZKPHT0Cr9QCTNQzBQBar0t?=
 =?us-ascii?Q?Gp8Pyisf7s40eziPlfuPZfjHxhaGXadqqFQXBOFRKoA2cP00jn++l61JJgmt?=
 =?us-ascii?Q?onS1qVsiYJs3AKn/cb7vmM8=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9594EEC17D301243B07ECE08F890FB28@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: a669264b-8261-4e02-eb48-08d9fe4bf28e
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2022 02:00:39.4309
 (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: X/PxBut3mEOCqAyX/L8WxfAScYd7BplADawhUokBfchhGaXeD6q9gzWVr2/Tps3PwIdwN77yr5FXZ09v3r13aA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3672
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10276 signatures=690470
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0
 suspectscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 spamscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2203050005
X-Proofpoint-ORIG-GUID: 2ypbhft9Es5zsMAGTDwoDw9x8_R_AJXK
X-Proofpoint-GUID: 2ypbhft9Es5zsMAGTDwoDw9x8_R_AJXK
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham 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 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 on
> an existing, unmodified vma; so it's right to assume that any necessary
> 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 range:
> so although the relevant set_policy() may have already been done on a par=
t
> 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?

>=20
> > > Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
>=20
> Thank you, your review is very welcome (but mainly I Cc'ed to alert
> you to how I'm probably stepping on your toes a little here - sorry).

Yes, I figured as much and I really appreciate it.  I'm quite confident
I translated this bug to my patch set.

Thanks,
Liam=