From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C07347082D for ; Mon, 6 Jul 2026 00:44:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783298685; cv=none; b=rMoRooIisWSYtCXi+0rF8PaJH+h4e+2oMfB1zE4/bMmBBpOY92zZhyPlGvUMfUrorSKaSx+xSe8tCDO2F/JyYbuZduUyVamI59ene0qZKHmlxKPdFKAL0drEbcrS8DF2WOLv1+Sf6yOrMfcSDL52JIFVl+tYqhuwsDFTc/ab2Bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783298685; c=relaxed/simple; bh=vbo/FXylQ849JkkJQqP/hUBLjerlSbtRfueQhso6BlQ=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=MvxYzBAehVuho7u9ZgZCe5zqHA/2oyMBQ2isISurx2jQwKiGlxBIQ2hY1VAG945oz9LjMVVhpnIhChqReHRi0AAVVM2TP3i6fA5OzewHpUAxttIYuVcg1wJ856XYzH8WbPp4dSpAuv14P783gwUXc/hXBeW/qyYffzVJcGvMv+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=xOP1sBW5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="xOP1sBW5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E1431F000E9; Mon, 6 Jul 2026 00:44:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783298684; bh=8ono3OPczy7q+WvHfQ9YIB/OU9xKW8rPIpMvkdre5TM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=xOP1sBW57M6RvqEa/nwhSk4qzx9lH3puJG8onkI34ewVq80xp+6nyBjyKu30lzAIl 0teBCB7x2q4oJcu4Tl+RHNJVfofADhVSc4WBgfx/bNW4WI4nrCi2jkwcRQ8L3zpZOP fDWjtMQCpWCR6equj+C0JT9LkI3AIDj483T8nWYo= Date: Sun, 5 Jul 2026 17:44:43 -0700 From: Andrew Morton To: Hajime Tazaki Cc: liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap() Message-Id: <20260705174443.08a11649b8e1c9e58e8cae22@linux-foundation.org> In-Reply-To: References: <20260702012830.667205-1-thehajime@gmail.com> <20260705151512.5edabd9bb5d11cb6f1c6309f@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 06 Jul 2026 09:19:02 +0900 Hajime Tazaki wrote: > > On Mon, 06 Jul 2026 07:15:12 +0900, > Andrew Morton wrote: > > > > On Thu, 2 Jul 2026 10:28:30 +0900 Hajime Tazaki wrote: > > > > > The sysctl variable vm.max_map_count (sysctl_max_map_count) is not > > > expose under !MMU case but used it wit the default vaule > > > DEFAULT_MAX_MAP_COUNT as a limit of count. This is currently used when > > > a vma entry is split into two chunks (split_vma()) but not used when > > > allocated (do_mmap()). As a result, even if users request a large > > > number of allocate memory, it will keep allocating until OOM happens. > > > > > > This commit introduces a check at the begining of do_mmap in nommu.c to > > > prevent this situation. > > > > > > This is detected with a LTP (Linux Test Project) test, which linked > > > below. > > > > AI review flagged a couple of issues in the current code, one quite > > serious: > > > > https://sashiko.dev/#/patchset/20260702012830.667205-1-thehajime@gmail.com > > I will follow up with another patch for the issue detected here. Great, thanks. > btw, I found (and sashiko also detected) several typos for this > particular patch. Can I send v2 patch with the additional fix, or do > you prefer that I'll only send the additional patch ? Ah. Well. Confession. I actually quietly fed your changelog through Gemini to fix up a few things, resulting in : The sysctl variable vm.max_map_count (sysctl_max_map_count) is not exposed : under !MMU configurations, but its default value (DEFAULT_MAX_MAP_COUNT) : is still used as a allocation limit. Currently, this limit is enforced : when a VMA entry is split into two chunks (split_vma()), but it is not : checked during initial allocation (do_mmap()). As a result, if a user : requests a large number of memory allocations, the system will continue : allocating until it hits an Out-Of-Memory (OOM) condition. : : This commit introduces a check at the beginning of do_mmap() in nommu.c to : prevent this situation. : : This issue was detected using the Linux Test Project (LTP) test linked : below. I did this "quietly" because it feels a bit rude telling people that their English isn't great ;) Lots of non-English speakers appear to be using LLMs on their changelogs nowadays and as long as they double-check the result, I think it's working very well!