Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Thu, 28 Sep 2023 13:06:09 -0400
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     Andrew Morton <akpm@linux-foundation.org>,
        maple-tree@lists.infradead.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Jann Horn <jannh@google.com>,
        Lorenzo Stoakes <lstoakes@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Suren Baghdasaryan <surenb@google.com>,
        Matthew Wilcox <willy@infradead.org>, stable@vger.kernel.org
Subject: Re: [PATCH 1/3] mmap: Fix vma_iterator in error path of vma_merge()
Message-ID: <20230928170609.uyugdslacbvaw5kc@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        maple-tree@lists.infradead.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Jann Horn <jannh@google.com>,
        Lorenzo Stoakes <lstoakes@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Suren Baghdasaryan <surenb@google.com>,
        Matthew Wilcox <willy@infradead.org>, stable@vger.kernel.org
References: <20230927160746.1928098-1-Liam.Howlett@oracle.com>
 <20230927160746.1928098-2-Liam.Howlett@oracle.com>
 <20230927101410.920fd8a88d2453f5c530aff3@linux-foundation.org>
 <20230927172649.tivg3yxtmzo3fzjb@revolver>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230927172649.tivg3yxtmzo3fzjb@revolver>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GB5AesVVTNwzNr+E0CbyCiH5tHIwi9BW/THeIjy15/VRROHrmwwZG/KNk6Kl?=
 =?us-ascii?Q?0cfEAOdcyU8X80NfH3wZBm3dFHhrsNJPKvTNv+xN1uyUNlYhZ1yTIJoHy2gU?=
 =?us-ascii?Q?xIIOUa6msbfkVHe8LPaD+thQv16g2TzvhTBoRDr1zEGZ8f6kuXANGBDFrp+c?=
 =?us-ascii?Q?TXpWhcMNgZc9N5Tmtypc+DFBDJG+lmkrVf1OuCzxpmJO/47zgoj34+EinLWb?=
 =?us-ascii?Q?HNrQF7JeBPPaufP20eSEakIzubueEKzo/Tljk6rYsAvWmvcB9wmDhmFgSmYh?=
 =?us-ascii?Q?FmDVSv9Ku5WhnDw/fm5pgVqYpTARVexLjY5asHVHNSdNpqfOsTLI74kWx9lu?=
 =?us-ascii?Q?Bai78PuPKa4wkO6abtdcsMKJ7MTHqbT980cFCS0G3esqo5xx4WevOMy8rJ3d?=
 =?us-ascii?Q?nrxnpbM55kGk+G01YJn2q8LKVaK4lldLxk08j5EexRf4d8MPWF2WerbvVx3J?=
 =?us-ascii?Q?Ie0ME5HNVqCTov+LeDAXUXtHFCqVk3qlGEcRCF6i6d0XY9xqEOknK/rEePTD?=
 =?us-ascii?Q?UMum7v3y4e3bP0hBl6dPImOcEZ941HdP9e2W5lgODRziR9ZOxH+IAFYf+MOp?=
 =?us-ascii?Q?hnrTOtEqUNzb0KEsxKbj9/AeB3Ge+pqIWORMOT+484RpggGNGMDctYQUjnSw?=
 =?us-ascii?Q?1yZSrmKWsXU4AIZDg1iGLxkZQkjcEzOMQl471m/2PGqFHWKetJdqISqsrhmN?=
 =?us-ascii?Q?i93k1PbUYMyQ/8iWuR16b31IeUekxgh1W218dfggR/4DqU0WYUINqbthT+rc?=
 =?us-ascii?Q?3wjvUmzNX5e+IMZxhign/PglT/WewQKYjKlPSSwK/hOS6nGrwxsjyZZHNx98?=
 =?us-ascii?Q?Gh1h5PBSumuWERvBuqeYFnwMDpNzhMa1/N/9XLv8GtmI8+wEY7D0m4cINV6/?=
 =?us-ascii?Q?Nlz90EElE/i8saZH6MCOJc3ZhZ8rdvfwq4Bw6kTtPskE8QppVsIznwg0sTYl?=
 =?us-ascii?Q?QC1w6ahSnhiYNMuNho/xG/EYL3LeVnIZziIMi+i9NnxpkRIj0AI4++r+vxFR?=
 =?us-ascii?Q?sNqwu/gds84Lup7BE9QmNRy1pv0qfczoK9ednMbc9e2JLunkIc1P8O7C9mQM?=
 =?us-ascii?Q?vAVEWPcu3OoVDZIWB/fa1L7dLF93B0xee1mydetRRtmixhlIPFb6qGWPcISR?=
 =?us-ascii?Q?YLz/tMqgtsQD6DiBcffiB97iPD25h1QHZCHA/GsqHS0qX60phYXbLLi0sPBU?=
 =?us-ascii?Q?SvdPzubDRwM8FZ5Ykdj6NCWwj9/kpjJzeUX8GjGi7GT1EbrK8G73fIBmjgjF?=
 =?us-ascii?Q?6RC8NWH337eczLmN44J+Og7dQ7Yv9npUkecYXK5wpkbsqGBqXLVvHHkrvABp?=
 =?us-ascii?Q?0flNer5Ezd96ZdXCBWGcHljyqZb44x5/BCPTRSQb9GLBRGr1gLFB/M/ofusz?=
 =?us-ascii?Q?589cyCtwK+5oZJe1ETclCKfEDMAolX6hro7VXvwZslT4bWbPDlSsqAl4BaZG?=
 =?us-ascii?Q?i8locmg8N6ArzgF19Ldj23kuEW3U8dEGDHRc7MRvWd/AnA28fDFkUTw67Y33?=
 =?us-ascii?Q?IxtFLvhkzrBu+Toh5TLpZTbGGHxplGC3wxpw8edzIuSDyL0c67CtOdVjqPCd?=
 =?us-ascii?Q?uAtF9f/hEvaMxxzAAWMt8ub9a3IMVm4H5R/4muif?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?H7DRsQeMF1i05raoba4AwIMTC5/gYj+o+hFB7w+5Pr++9BbX77ftC9sXVzsX?=
 =?us-ascii?Q?Kk5BCGC9exKKRIjLZ3N/nBvMDC1x7RAkjOfwDWbqIVSjzFniwNiW5uy1a9uH?=
 =?us-ascii?Q?6k7EnAP9HrDl3PTlwj6y2nTHB1UG2MccWb+UUmeuDLGyNv9Zb2uWNLmIaO1h?=
 =?us-ascii?Q?vylabxxLYquF9F4ET9zYtiPLV5XpswfnUzHeigOWhRKzbxQgKR/pctzO7fdZ?=
 =?us-ascii?Q?kjNberMK3LE4dd7/De9dLvQ3ldktYrL3B6NkpLPIGTpjBGDuFHSMP6PEhzr+?=
 =?us-ascii?Q?yCpCwyYBplITKN8FjAaRsqFA5Ot6YO9GIUJISa7sbwkngeUGaJbQWe4y+LNi?=
 =?us-ascii?Q?H0HOoX3eqZmBhWdfYeek96ZwuNKnrZ04WOE8ksrn3n+kIYR30wxxgv7OHsLZ?=
 =?us-ascii?Q?Xs5S5r/x7GJaCeYpctG/vbBFRzrbPA70DJfYnHwHVCZfBLzh/wMIW0C/nIUN?=
 =?us-ascii?Q?v7hEZC9QkKwBBvhRBjGyJXLDy9My4fZtW3385sGGg7Byyd7yobjIfMQoCwjF?=
 =?us-ascii?Q?kHOEcBd0Y2pPpnv2yLFYtjRLj96P9IadI++5vjsPHGwmEBxvUH4hgkzTKo00?=
 =?us-ascii?Q?K5VKZUtGNIjj8g55vMXfRDpSZ8LjreRS1MugDMsN8/bOJVxkfIlo3Uh2lFcn?=
 =?us-ascii?Q?vAvDLvguDVJrWHWnzd8Quzqf3R48F/rz2d5PSMb2Bp1aPZp/bKLTE8/qPXWJ?=
 =?us-ascii?Q?QOXpoUmPn6kxE7KXDEp9QIJ+1/TfYnl6wbGwC1B+gvLFVkgygq6UD6ame1KB?=
 =?us-ascii?Q?iDyclHnbzV13QZU6wtKV68rnOjrp3FTfYl+6rm+OlGuBUwU1SAWG8DfM3cEu?=
 =?us-ascii?Q?XQxvzVjTxTaAf/YGGbhLDbHVMdUI+oPNESYdLTeCLtR76IGW2aL/prDPhnvU?=
 =?us-ascii?Q?w+m9rTiD7DfUckAuQtEQfL4YF+CEO64Hcx9ISEtfrVJOkrSiQJYGVX9iFLhI?=
 =?us-ascii?Q?jqdMficYk8kALrM09FiXXOfqyZdQSgap7KSOYB4SgZhZMYdVJMIIehVlgb5i?=
 =?us-ascii?Q?v3FE?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c6ab623-8d9e-47fd-ed9e-08dbc04537fc
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2023 17:06:12.9898
 (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: 6iiNmJxzHVV3DO9z/7jD8rY5nXhikKPx5dv8KJtOajiuxz5UgJLhRpMmrOjRqKJzkya/pBFDP5lt4UZed7aMtQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6031
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-09-28_16,2023-09-28_03,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxscore=0
 spamscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000
 definitions=main-2309280149
X-Proofpoint-GUID: Fqslbb28uQK5G8NL5IXMyJ0aiDRXMuab
X-Proofpoint-ORIG-GUID: Fqslbb28uQK5G8NL5IXMyJ0aiDRXMuab
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 28 Sep 2023 10:07:29 -0700 (PDT)

* Liam R. Howlett <Liam.Howlett@Oracle.com> [230927 13:26]:
> * Andrew Morton <akpm@linux-foundation.org> [230927 13:14]:
> > On Wed, 27 Sep 2023 12:07:44 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
> > 
> > > When merging of the previous VMA fails after the vma iterator has been
> > > moved to the previous entry, the vma iterator must be advanced to ensure
> > > the caller takes the correct action on the next vma iterator event.  Fix
> > > this by adding a vma_next() call to the error path.
> > > 
> > > Users may experience higher CPU usage, most likely in very low memory
> > > situations.
> > 
> > Looking through this thread:
> > 
> > > Closes: https://lore.kernel.org/linux-mm/CAG48ez12VN1JAOtTNMY+Y2YnsU45yL5giS-Qn=ejtiHpgJAbdQ@mail.gmail.com/
> > 
> > I'm seeing no indication that the effect is CPU consumption?  Jann is
> > excpecting bogus oom-killing?
> 
> His testing injected a bogus oom, but since the vma iterator may get
> stuck in a "I can merge! oh, I'm out of memory" loop due to the
> vma_merge() called with the same VMA in this loop, I would expect it to
> be increased CPU usage when almost out of memory until a task is killed.
> I don't think he expected a bogus OOM since we are using GFP_KERNEL
> during mm/internal.h:vma_iter_prealloc() calls.

The initial call to vma_merge() is correct, but on the second call vma
is the same as prev so it won't attempt to merge prev again.  I think it
would only cause one extra call to vma_merge().

So I think you are correct, CPU usage will not increase very much.
But, there also will not be a bogus OOM.  There will just be two calls to
vma_merge() for the same VMA when there is an OOM even and we could have
merged prev.

I doubt the user would notice anything and they have bigger memory
issues at that time.