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:     Catalin Marinas <catalin.marinas@arm.com>
CC:     Mark Brown <broonie@kernel.org>, Will Deacon <will@kernel.org>,
        "maple-tree@lists.infradead.org" <maple-tree@lists.infradead.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v13 57/70] mm/mlock: use vma iterator and maple state
 instead of vma linked list
Thread-Topic: [PATCH v13 57/70] mm/mlock: use vma iterator and maple state
 instead of vma linked list
Thread-Index: AQHYtjjC5w5a5sxoDUK1UuyGlVOoOa2+yHEAgADWHwCAACFQAIAAVDEA
Date:   Thu, 25 Aug 2022 20:21:35 +0000
Message-ID: <20220825202128.6a4pzhdntc7xsok4@revolver>
References: <20220822150128.1562046-1-Liam.Howlett@oracle.com>
 <20220822150128.1562046-58-Liam.Howlett@oracle.com>
 <YwbDmKyQxWHfRg97@sirena.org.uk> <20220825132054.ymenz4cewiemsxw7@revolver>
 <YweTKGvxzpUnbTkk@arm.com>
In-Reply-To: <YweTKGvxzpUnbTkk@arm.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?2pcC6IaAjc3wdAfkjsV4hb/NavG356a6eRaQ9aRSRFH07XgWiZvbnbgaJGZJ?=
 =?us-ascii?Q?W89SDhEzFtWOQnO2/rWpTagxtu01WLYN0X4a2L9pKQNY24j4T5jGObjkgcF9?=
 =?us-ascii?Q?3R6IGh7GUatxJlZf3zCflp10G0HCaPs5FHqiC11QDngkfiFY5tbRPPLWpq6H?=
 =?us-ascii?Q?OlzRO1GBUFaEN9yCdsF1pO1lbloemmTUkwW9j78kTMZXucpAeZ5OLGNblQfx?=
 =?us-ascii?Q?nCAVvwpN3sVGVD4BtUEo6iJLoSbzlnZXfr+y3YQWhJQgOz+UzWbu2EqbOTEk?=
 =?us-ascii?Q?1w5Q/69b+8Y4pKsX+izd/2A+lhdm7ZwrKjqh/tPlxfg5r9zjCnKkctLFXYcL?=
 =?us-ascii?Q?QPAgREN7MO0zS/lKF6p/4MYTpa5FR8Hs897F+BMnZYLup3Le10dv4YafdSxx?=
 =?us-ascii?Q?DGdlyGsPY8mJSx9DxduI8osU9gr1SJw97PNii0jw2hoqZfOjCaECRxdyewM7?=
 =?us-ascii?Q?Ns2eqXbesKmcoX6vRPKgXufg+KU9W6hYOKdnV5ElfXDmROL/ect7JliWdh7H?=
 =?us-ascii?Q?KO3Pc9vUwz444SsSy01KBbrlCe1XLVkNpY24I3gC/QAayv/g1wAHCIvvhFvy?=
 =?us-ascii?Q?pZTaCOpMX3psQ1RZn1Yh0WMJTB3AIpVj7C0NuZXD5RsS1Ep1a1mGKyBz0x7l?=
 =?us-ascii?Q?R/pZQQAxgEwhBA62OqyUz33s2QfjxMmZQxpYEMWYvbAqvClzaPaRU+QuvWh1?=
 =?us-ascii?Q?l1T+NDmEddFbfz2FNapAbAXmwXYr40H37fxMdtHaamUMhOvUwWbcbGTkYZLm?=
 =?us-ascii?Q?Mt8BYQS0umA2krXG774IufH9Q/XBPwXjD7qYGgl33EHWsVXJTTMq6svL+SnR?=
 =?us-ascii?Q?rIF8mCYNVQwYFXJl9008caO3Q+TiECOzF1QPdzrXUE41hyoQEEik+m3JNHPV?=
 =?us-ascii?Q?YBRn4VNc1JtL1nFNaX6ejy5ZGlYy/RiAE9PbYiAOl9rZjEsadkBTeTMn+/wQ?=
 =?us-ascii?Q?JMaN3ijO8Fe7pobwJPAypkRhgtQJuoi4vzfrZADRzPNuyqe85zCFBXJWfo0r?=
 =?us-ascii?Q?vB/VJUNzo42dgP5FifOumkXn5uMDEo56qoNnJvUY1F9q5+DYXMZ21e0jkhdN?=
 =?us-ascii?Q?1uVd1SDF9AAzxlrAMVSv2OkCzVeVJ7rARXbmsSgPCJqbz8puBuP71rkSFvIs?=
 =?us-ascii?Q?slhBJEtWbrNFyhiTHMozFqaBKiZcqGQUbxAWFDTJT0Q2f4sCt3rtw+cv0ZJ1?=
 =?us-ascii?Q?llEDGTmyKHNcmnPyu9n0eyfTGEtJac8GUucmd6rYq1+rE1Wil5bc6h2Or5m7?=
 =?us-ascii?Q?NZlRLXlDFqgyDWZpDJj/qemYfGAmt6fFYrKiSWd6IpjkO4bjFk+r91lIa/Bo?=
 =?us-ascii?Q?/MiRHMZCY291/WNTReJIbHbdTBvwYn/kZyo7fB6/TRGB8VbhXJhnvSArDZVv?=
 =?us-ascii?Q?GXa0XZBb9y7VO32dCfniGduqCC4KZpigweA9LndnA8xBoJhqjHLtF4HOqRx1?=
 =?us-ascii?Q?B+bTxfwyc1fN2fnyc+wJlLNa4elcTX3XHTblR7JZiOXQ79G0fPoN9xoD2gjf?=
 =?us-ascii?Q?Pt6Zqy/JUBEEosMAbbcqh5DhsUJD/UqTZNV3whgbwVJtHWcvh9LNvlOUQamw?=
 =?us-ascii?Q?3gAka45EnC0Cu1/b+x/4n3H7YrXqNS2+l095wAfkpgDTShPftec8MqLJpRFg?=
 =?us-ascii?Q?CA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D9244E68BE39A742A55D7F940F629E32@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: 468df39b-30e7-411f-cee8-08da86d7689c
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2022 20:21:35.6919
 (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: gD40yNSK2+iTbWjNR5xfY6prceQV8ef9pse+REHz/9NRyZmjo2RddHYb7cBRb7yT+EDh8N0l6YhoV5v99G8wGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1742
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-25_10,2022-08-25_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=925 mlxscore=0 spamscore=0
 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000
 definitions=main-2208250078
X-Proofpoint-ORIG-GUID: hPHvWBpSfvHr8ZrElxpru8Cw4_aTv_kv
X-Proofpoint-GUID: hPHvWBpSfvHr8ZrElxpru8Cw4_aTv_kv
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_H2,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

* Catalin Marinas <catalin.marinas@arm.com> [220825 11:20]:
> On Thu, Aug 25, 2022 at 01:21:01PM +0000, Liam Howlett wrote:
> > * Mark Brown <broonie@kernel.org> [220824 20:34]:
> > > On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> > > > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> > > >=20
> > > > Handle overflow checking in count_mm_mlocked_page_nr() differently.
> > >=20
> > > Our QA team found that since next-20220823 we're seeing a couple of t=
est
> > > failures in the check_mmap_options kselftest on arm64 platforms with =
MTE
> > > that aren't present in mainline:
> > >=20
> > > # # FAIL: mprotect not ignoring clear PROT_MTE property
> > > # not ok 21 Check clear PROT_MTE flags with private mapping, sync err=
or mode and mmap memory
> > > # # FAIL: mprotect not ignoring clear PROT_MTE property
> > > # not ok 22 Check clear PROT_MTE flags with private mapping and sync =
error mode and mmap/mprotect memory
> >=20
> > Thanks.
> >=20
> > > I bisected this using qemu[1] which landed on 4ceb4bca479d41a
> > > ("mm/mprotect: use maple tree navigation instead of vma linked list")=
,
> > > though I'm not 100% sure I trust the specific identification of the
> > > commit I'm pretty confident it's at the very least in this series.  I=
've
> > > not done any analysis of the failure beyond getting this bisect resul=
t.
> > >=20
> > > [1] qemu -smp cpus=3D4 -cpu max -machine virt,gic-version=3D3,mte=3Do=
n
> >=20
> > This helps a lot.  I think your bisect is accurate:
> >=20
> > ...
> >         struct mmu_gather tlb;
> > +       MA_STATE(mas, &current->mm->mm_mt, start, start);
> > =20
> >         start =3D untagged_addr(start);
> > ...
> >=20
> > It looks like I search against the tagged address.  I should initialize
> > the state to 0 and mas_set(&mas, start) after untagging the address.
> >=20
> > I'll send out a patch once I have recreated and verified this is the
> > issue.
>=20
> Thanks. I did a quick test and untagging start seems to fix the issue (I
> was wondering why mprotect() returned -ENOMEM when failing).
>=20

Thanks Catalin for testing this.

I can confirm this fixes test 21 and 22 above:
ok 21 Check clear PROT_MTE flags with private mapping, sync error mode
and mmap memory
ok 22 Check clear PROT_MTE flags with private mapping and sync error
mode and mmap/mprotect memory
# Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0

I will send out an update patch shortly.

Regards,
Liam