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>,
        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+KyvkiKAgAAEfoA=
Date:   Fri, 4 Mar 2022 19:05:38 +0000
Message-ID: <20220304190531.6giqbnnaka4xhovx@revolver>
References: <319e4db9-64ae-4bca-92f0-ade85d342ff@google.com>
 <20220304184927.vkq6ewn6uqtcesma@revolver>
In-Reply-To: <20220304184927.vkq6ewn6uqtcesma@revolver>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9f5j3qBPK8NKSrRJiKZ+TpIfaRI+invdZqmelH4jH/StrlRRTS9KT9WjFOjt?=
 =?us-ascii?Q?mL/cyCS8rnz62Q7eZj8U8e0UyabtUphBp/D57oLI6VQ69OPePtwlP0kuqxW6?=
 =?us-ascii?Q?gEJGo4yXnCGIM5RB+jp9BuhdS+90yT6vF+Tk+d43nS4ROXGdxA48FUocAGoa?=
 =?us-ascii?Q?12Ia7dvyWz9GRrR0VSTO73wVtPPdSZgp5UUrOHL21Wij+8KJ0DbF4gCggvWl?=
 =?us-ascii?Q?tqLInk1299uaghkiIXF7qK+i2B9UZroY0udp09c2UZS0wk0l7/ZN6Us9hiSG?=
 =?us-ascii?Q?qrPQ827Mlu0une6h5RKtYxoRw6q0ZDunkz9mkOpsozhLhkM9fsLzYNcknnUD?=
 =?us-ascii?Q?fz5T1X5Mivu9onWz3VV+aLdGENb5QmQyFvs1ojPjqRN2STmUL28PC7HdeqmJ?=
 =?us-ascii?Q?RpEQkGV87b/98A1QrIjHWG3WmDarYrRQ6p53aYliuYl0SHa4r58DeSZmd6dp?=
 =?us-ascii?Q?hxX9nQwxkfAB31uZ8pljWECItImQ0ABd7rAdsivAWaThyNDB01J+EVAPAo2G?=
 =?us-ascii?Q?mxJv7bgZTelJhjfugsGAceL/fGPbMASlOhb5+AGB4ZwSJv3Jmpd5XZLtcm+w?=
 =?us-ascii?Q?rfJm4G6ssxuCU16BfGTbNM6gujguispWePx14l26C6AHjfyL3rljMXjdc+nE?=
 =?us-ascii?Q?7qb8eKNcxxZMzBJwYYkMpxKupQYU4Uv7vnAlQDUh+Uj3yQn3SuLuKK3XInjL?=
 =?us-ascii?Q?CWKCaZtJrHZC1vYnUh/fif5aEngcILXPqtpln3p+XsyDZYnJpjM/c61Fy6Mw?=
 =?us-ascii?Q?rHLuy+iZ5sBrUxx8xCsviSyNtXFlecGRhWH4G1R0thkdV832fmNX6ei8FHTN?=
 =?us-ascii?Q?438GkZuONXeCzYvciiQ3jFNAKfgT4Oe9YMnmUjIur1MGtVRaRa5lJbwglpwi?=
 =?us-ascii?Q?pN5N71M4TH71lwowDiBAMVCHWPqQQ6BcOZgmpiGgQDGcP70a0BA1+86i9iRH?=
 =?us-ascii?Q?3yxH7+4GsXrUl56G2hP451C2IflXnmFXULGKabyyHQguv89k2rNol8SX2EWI?=
 =?us-ascii?Q?OlWv9KFV1zfSrYowNQ3fHZ7BEx9Thj2ItOmI9Df6tXkhBEp8fV0xKFCyguUo?=
 =?us-ascii?Q?g9UgQKBrvgfOb4dz9wMiAYGevou7A6obxxO4n3i0clreSXYkEKFpvb4AecOO?=
 =?us-ascii?Q?bUm7cS3eiPdBcRf/hfyZeztM0TmfcSGVD3bvVO91UNYHnSAbIqDEvJ7IdrMQ?=
 =?us-ascii?Q?H05vRLhBynfic5ajzLu7NLRVUWg4O06az4RRD5q8ckNurVhKskj31Y/aVp/W?=
 =?us-ascii?Q?mxJdivj0UlJqlkmJkkpbV4wJvPI7eV7il1NALDoOZXTLKa1iL4H0fg6/Jced?=
 =?us-ascii?Q?0YXr4NNRw140ogj320jo/lidtzrK19TlgtDYcJuxskUtMbtfGJuROu4V1jNO?=
 =?us-ascii?Q?7DPgCPl8iz1+IdL9XkcXSlgp3Tl4mas/T26rHTJZ1EWGvi3A+vtzK3qZxqCi?=
 =?us-ascii?Q?5C7/E9WG/abuQwPw3KIYOWedYNHnpsIKtN+CQdYO9/N03S/opWXYsCSyqrdi?=
 =?us-ascii?Q?gWcCjxYEM1AZf8pn7w4kgVoMS/SoK0EsFc1fz9+p3S2k1xIX3LNbUpOPOVIM?=
 =?us-ascii?Q?weF2/QhfRumI2bAUidPQVnWmZ0/hyww3qLCvbQ0SwHwk7TICDx4R3BUvInN2?=
 =?us-ascii?Q?nxsCG0N9BPlDvMkyjvyCFMs=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E564D1131C39447A89BE8323FABFD46@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: f0f631c8-4087-45d0-e043-08d9fe11f82c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2022 19:05:38.0913
 (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: YMeA4UtgRBLG3o1hBl5WxVl4ZfLl7YuZivOlnf7Fzd4HZdSZkUxOGcB3mU8dEycoipuiK++LuW86QUKQJ5Naig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4614
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10276 signatures=690470
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 adultscore=0
 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2203040094
X-Proofpoint-ORIG-GUID: _Hk2aQZBQi-PMk8PWWRDKDinBg_N-OGN
X-Proofpoint-GUID: _Hk2aQZBQi-PMk8PWWRDKDinBg_N-OGN
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

* Liam R. Howlett <Liam.Howlett@Oracle.com> [220304 13:49]:
> * Hugh Dickins <hughd@google.com> [220303 23:36]:
> > 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.
> >=20
> > v3.10 commit 1444f92c8498 ("mm: merging memory blocks resets mempolicy"=
)
> > tried to fix that in vma_adjust(), without fully understanding the issu=
e.
> >=20
> > 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.
> >=20

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?


> > 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.
> >=20
> > Fixes: 3964acd0dbec ("mm: mempolicy: fix mbind_range() && vma_adjust() =
interaction")
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > ---
> >=20
> >  mm/mempolicy.c | 8 +-------
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> >=20
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -786,7 +786,6 @@ static int vma_replace_policy(struct vm_area_struct=
 *vma,
> >  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 =3D 0;
> > @@ -801,8 +800,7 @@ static int mbind_range(struct mm_struct *mm, unsign=
ed long start,
> >  	if (start > vma->vm_start)
> >  		prev =3D vma;
> > =20
> > -	for (; vma && vma->vm_start < end; prev =3D vma, vma =3D next) {
> > -		next =3D vma->vm_next;
> > +	for (; vma && vma->vm_start < end; prev =3D vma, vma =3D vma->vm_next=
) {
> >  		vmstart =3D max(start, vma->vm_start);
> >  		vmend   =3D min(end, vma->vm_end);
> > =20
> > @@ -817,10 +815,6 @@ static int mbind_range(struct mm_struct *mm, unsig=
ned long start,
> >  				 anon_vma_name(vma));
> >  		if (prev) {
> >  			vma =3D prev;
> > -			next =3D 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 !=3D vmstart) {
>=20
> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>=