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:     Mark Brown <broonie@kernel.org>
CC:     Catalin Marinas <catalin.marinas@arm.com>,
        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+yHEAgADWHwA=
Date:   Thu, 25 Aug 2022 13:21:01 +0000
Message-ID: <20220825132054.ymenz4cewiemsxw7@revolver>
References: <20220822150128.1562046-1-Liam.Howlett@oracle.com>
 <20220822150128.1562046-58-Liam.Howlett@oracle.com>
 <YwbDmKyQxWHfRg97@sirena.org.uk>
In-Reply-To: <YwbDmKyQxWHfRg97@sirena.org.uk>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?meOcNjs73XzFjviaYzdCJQfICgJT9TEMP+0+Cpt8OVSMsyfivs13Qk1U8tlv?=
 =?us-ascii?Q?b2qoH88oRR+g1EVZxNTUew+nPbEILOxZvNJ3xNFinwdJNUza1fLktpPp9fVz?=
 =?us-ascii?Q?7y8eCMyfXCaqQN7TI1dV7AIADCNUc3C8+4XWEYRELd7WC2sbWQvZ9H6RpzA7?=
 =?us-ascii?Q?LMUAfPXngfJjPY96stlPOVX+G1Y1xs6+pavPk8NbaFCouCD0v2bu0hDvjuzf?=
 =?us-ascii?Q?OLRNyIq3TeJ74F0F4V/saguQVr7nCvLR2tcr0MPy2eu1xz2MUH6Kix1pugCC?=
 =?us-ascii?Q?RqYxoXSIOhSf3Xze/ENnzRYNVwj11cl1HRXZM5rojVQ7be/KmccG6JyhWLMl?=
 =?us-ascii?Q?op8mv7v1yYkzoyYuznVrmdC/9A1eFZGc9Xk5SmQrN8JQO7J2kpkZBYTTIdqp?=
 =?us-ascii?Q?v9hCrNEqYqO0S5+r2ClaP4Aj4r1SqySK3PWScnnIPuX+a6JsMCoHkYPdsNg3?=
 =?us-ascii?Q?wVly8aIRxpvE2TlnTorlKFg8sJjCkm5My9Ddqy0Hw8kniE/nhq7me26uc2Fu?=
 =?us-ascii?Q?F2siPCqyMG1nmhbqopFfTBAr78MjOjcgsZc7JgyBhRX625S+pWeOeitbJZd2?=
 =?us-ascii?Q?EfxwT6Vh7PPtJQk6fZEJLdro1Qy6Vs3jpwnCOCgK2EYl5jsyPKo+QIlVsAjJ?=
 =?us-ascii?Q?m+sHCqF7gLSgh8iDhe7Px8nXyC98+qDwixogaKYQ7rqBB1Q91YjQZ7JdIWfR?=
 =?us-ascii?Q?vbWXabMXEXvXB/brQxMfvo+ep28XSN7OYuNFkizmTiPzLTb+lYYsqQrqBZdU?=
 =?us-ascii?Q?96i0BCU3ZdjZHF6JSoC3oofpu3gQVN8Rm04KEixudo8WTDHAVYH8nf2eCOjC?=
 =?us-ascii?Q?EdmlhSrJizuhZGhJU0jKLYa4Rfv6rMOC2FIoKgV/eGpisWBUqsi4oDMIN+Ff?=
 =?us-ascii?Q?pIg9aJBnlhvy30Ccpj3GgBwPGQPc0WqpHNOdPkY73GebMH6HEMICIYH7JpMt?=
 =?us-ascii?Q?HZo/CPyILOOfMeYuZymV3ajNilwsdMUNvie6JuHt2k9IFqTiev6W4PnohBE4?=
 =?us-ascii?Q?5FxGYmWIGXwKB7ufGDGXmRIOU1IlhAb3+pPYA/1O5nVPQuKTncKd+fRGSUsC?=
 =?us-ascii?Q?lyxDMi2zq+0PXBEmi9fXONjrkROBUaAz+cOxxMwldUrtdczwQAsHeqnPNf8D?=
 =?us-ascii?Q?x4q6nYTTm0R4OpM1di65KkDCWd5Q28NmJlrcu/2wY4BS3vSK28sLFnFXkxK8?=
 =?us-ascii?Q?vc/u8Yn13gDN8e5uUbWPf53lULbm4nMDHShkSHiEAATNoSeYlUI5GS8ngAYO?=
 =?us-ascii?Q?ezVE4rR0BOd9mrckYsFPUKdjuHVsWRzbc7EDfwwXH0uhipMCAW9fgoVBFiqA?=
 =?us-ascii?Q?8gaA805uKzK5UxZkpAcTlPEnbPvGhP4gb2thapmaYwX/ycl2FrdfcMdgpfRu?=
 =?us-ascii?Q?EPkLUvHyHNE51iS6gc3xAAYzYTwlskD1ZMPTBWkOjxqpDgVnm2oKKbtGMajR?=
 =?us-ascii?Q?SFZaOUtluF/YTWhkq98wzbUY+RfMe+vhCEvg3iqD/3HNBlQVc5PuMNCBGzoc?=
 =?us-ascii?Q?ZkVKGZ6xjt2b+Ff4g5bB02UgEC9owzY/bvpcX6zM/TVZFeoF40OkMrjMshl+?=
 =?us-ascii?Q?XZal9W2xeduHSt3l+MndO6kBZSli5dJsQqW0PQElhL6JC6gXl8cP1SHN+BBy?=
 =?us-ascii?Q?3Q=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1F6D6A06183C924B9948589C3B2EF33C@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: b7250025-8c30-4dbd-80a0-08da869ca865
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2022 13:21:02.3966
 (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: ruvymTb1yrNOGqmwsFegJmTaZp9aKlDW8X/CLcieA9NZGKCFHkvV7qp1pwWgidMlHu98DEy6ea1zbnde3I1eOQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB4966
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_05,2022-08-25_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 phishscore=0
 spamscore=0 malwarescore=0 mlxlogscore=863 suspectscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000
 definitions=main-2208250051
X-Proofpoint-ORIG-GUID: gtejXBfS23gC1aypFIh2iuJCcc-NkYAD
X-Proofpoint-GUID: gtejXBfS23gC1aypFIh2iuJCcc-NkYAD
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

* 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 test
> 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 error m=
ode and mmap memory
> # # FAIL: mprotect not ignoring clear PROT_MTE property
> # not ok 22 Check clear PROT_MTE flags with private mapping and sync erro=
r mode and mmap/mprotect memory

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 result.
>=20
> [1] qemu -smp cpus=3D4 -cpu max -machine virt,gic-version=3D3,mte=3Don

This helps a lot.  I think your bisect is accurate:

...
        struct mmu_gather tlb;
+       MA_STATE(mas, &current->mm->mm_mt, start, start);
=20
        start =3D untagged_addr(start);
...

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.

I'll send out a patch once I have recreated and verified this is the
issue.

Cheers,
Liam=