From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A027CE67480 for ; Thu, 31 Oct 2024 20:48:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E1236B0082; Thu, 31 Oct 2024 16:48:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 091346B0083; Thu, 31 Oct 2024 16:48:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC0EE6B0085; Thu, 31 Oct 2024 16:48:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D47C96B0082 for ; Thu, 31 Oct 2024 16:48:19 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 58A841A18DD for ; Thu, 31 Oct 2024 20:48:19 +0000 (UTC) X-FDA: 82735083606.09.16B5AB2 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf03.hostedemail.com (Postfix) with ESMTP id E274C2000E for ; Thu, 31 Oct 2024 20:48:04 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=QrHWF7ZC; dmarc=none; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730407535; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=f8OD+ud8Q/1hv58mQTpH/SSMAR/ftwkhG5c7T0rE5gQ=; b=G0DEG3X6tD8Q8Y5+eu1nQthkzyFjl47Nip31T1FA7L6db+07ubDdw2PNBvF4lxmiHvS0tt AEywwNCAjiZE13I7D6PEOnp7mY/j6mkazE2z9QiO7vFFSNkzI15ZBnwJcfVN+LKbLensAl MEuwQpBxu1j3si1NNFNAh/IHsOU3npY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=QrHWF7ZC; dmarc=none; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730407535; a=rsa-sha256; cv=none; b=4l131bLeC9wK8lkYZ0m0Z6QJ+xncV8mlNlwXjyO/xqs3ft8TQYLZ/7EsYOdXXnwVv+64n0 iabqr2V07EqrfQRg7H7AcceEHaejcyACQxGmXnjRL4MJBM1lPfTO0itYwmNVfmg+z3mZY1 5QSzixBlnucdT5C/d9X0vnPEbQJFzog= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 3BE5FA443F7; Thu, 31 Oct 2024 20:46:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43751C4CEC3; Thu, 31 Oct 2024 20:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1730407696; bh=9Rlt00csn4oRCGDp3EcDh3UdakjPlx4n+2L1g7gkZ30=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QrHWF7ZCs3rd87P+eRFI3e3vN1RKhsTc7/MLt72fQCopoduSiXG+GdcpV+//okSAq svOC6Eq2KKwe0pGKjVnC1NPWVdlOHGnRnLTTTYNjHnDZKdQj6RtmTDm1qJbv5BVpq7 lVV6umUQanly6VpsAZF5mNxYlK1YrxWv23utLzI8= Date: Thu, 31 Oct 2024 13:48:15 -0700 From: Andrew Morton To: "Liam R. Howlett" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn Subject: Re: [PATCH v2] vma: Detect infinite loop in vma tree Message-Id: <20241031134815.81766b263e87f74a3e31471e@linux-foundation.org> In-Reply-To: <20241031193608.1965366-1-Liam.Howlett@oracle.com> References: <20241031193608.1965366-1-Liam.Howlett@oracle.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E274C2000E X-Stat-Signature: eqz6xjec1bdn15o1p1pq438d68e5u8rq X-Rspam-User: X-HE-Tag: 1730407684-799554 X-HE-Meta: U2FsdGVkX185p8IGd11YDUhkne4BHwQ4nWrNjBkRDhZt+oYYpYk0vCc4GWGMW9h4dvliO4xSLrBLnkGj46i/3x/JjF8QBdsY4md+kIzox0Wh4V6yLCfXb/WkHgo2VKKC78MGJazmpv9SclyyeprJgPhb/IpKKfDD3IZXwCFLgz8lpZs2Dl8nbM1KMzWpflG2zRU83YtURp6vlVNG12/ny3F2tNRf57x6mcu9XkmsS6JpOl1nfYfuuu5IJwe90+AXCNkdQ3J2VXoJM63eGIq4bNxHsv9qm2I0F2bOknuh57gazfSZcsZMTOdseXdcYB1KHtX2C18wVPBGi2qgJR0bTdbDQpxCvaAlOSdS300agDOqFWmEgYmagPsFPBzVNGkrMvSMIoM+VPKjMeCAPz57RApMFPUy8WpWfqCft9J16DABVOwBYfju3kEG1PnL2dQ0WMDBgQYTi+CnQOuRIl6v+f978DU4Dw9AnQCHWSAx7IWWSvSVToZEcc7k0l957YCNhInU+VZOWVNtWBRcoNsKktFDtMjzdCgOREI0IeEEVOxepleE9zdTCwCfwsiXJBVz4nJs3LIPqLNasvTtSC+qbpelKvTAEmz6G3mfOkjlJEQLn0TUG2dh03411wNiHMsN1YgsxcNvKyafEzZrhRvFT+CcnwG2r7+dyyQIC3+HlPCQGltqgWkFz2hfDzR4rq0CU4engXPvPB/FrgmR2qA04mPHsATGWZqbPtCDxutT1Ony6pgb+4VVgQXLRWsDdla4K5M5nymobVPRxRRhwCPmoJe73+rX/A22pEM++yWU/aWMwtJ8GCty01jocLkChUXPczFlt1wceNhgdd08/VyQYkhCWYUUdyOfMX3td6QSdLuTEhDNXPiYP0HQQKaYfLtQLvukzvRoNaGRqcoZSdjRkmawa9zLIV6hW7XokN/patu0oYRjvFGco2IceltXNvbFmywly4BSR0cSrI+YuwI z0DCpzCv fST+V38wp8cEYM1qs1M4LZEGl3jxsNRt+2+ZOIMttQRiiYmkEXyz2jtUeLBSrLhd1VmdrBPsN1ouHW9Z0SNROCgvejiq4vyt5lL3SKFHsjtr8+ssLRqleL36Cc/i1dKD1z7+RLWoz41+CSrfBdT8jpDnL7kcbxN4e7RaF/e8oLOgX53NsYCtNxnVP/7maECu2c1cPVBwATVAllpHZan3GxO3mk6XKkDMkXLOM/Fmj2vL4TLoyNSBqjkxlQiMJXMCViD+q7E/zRg2KMUg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 31 Oct 2024 15:36:08 -0400 "Liam R. Howlett" wrote: > From: "Liam R. Howlett" > > There have been no reported infinite loops in the tree, but checking the > detection of an infinite loop during validation is simple enough. Add > the detection to the validate_mm() function so that error reports are > clear and don't just report stalls. > > This does not protect against internal maple tree issues, but it does > detect too many vmas being returned from the tree. > > The variance of +10 is to allow for the debugging output to be more useful for > nearly correct counts. In the event of more than 10 over the map_count, the > count will be set to -1 for easier identification of a potential infinite loop. > > Note that the mmap lock is held to ensure a consistent tree state during the > validation process. > > ... > > +++ b/mm/vma.c > @@ -615,7 +615,10 @@ void validate_mm(struct mm_struct *mm) > anon_vma_unlock_read(anon_vma); > } > #endif > - i++; > + if (++i > mm->map_count + 10) { > + i = -1; > + break; > + } > } > if (i != mm->map_count) { > pr_emerg("map_count %d vma iterator %d\n", mm->map_count, i); It might be helpful to tell readers what's going on here? --- a/mm/vma.c~vma-detect-infinite-loop-in-vma-tree-fix +++ a/mm/vma.c @@ -615,6 +615,7 @@ void validate_mm(struct mm_struct *mm) anon_vma_unlock_read(anon_vma); } #endif + /* Check for a infinite loop */ if (++i > mm->map_count + 10) { i = -1; break; _