From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-a3-smtp.messagingengine.com (flow-a3-smtp.messagingengine.com [103.168.172.138]) (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 1996A31E85B; Sat, 26 Sep 2026 17:14:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790442891; cv=none; b=ikGqtDyotU4vLW1m0H2ZSA90ZHJD4lX/4QPHjebIl7PvkbNsltWobnO0xDyiheF4kGEEYviUQZNc0Sy9be9HZUD62SgxEM2GyMIJSCjlwL1rkYtI0myf3PkDl4SQkYERH1b7c0SofCRPFC8Ydnxc760/9pLbl1CPRwt1Y8Bd5Z4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790442891; c=relaxed/simple; bh=gojmdYDsD3StNnB/hDyqo1gXIHc8O8nZybk73It5oqU=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=nAA/WlIzbixDsH7/i+ccnmt0/NrHTEngYwj2+yPDdK2pqxFX41f+CdQ6dgIGCk0WoW+DK/WA/1QXux5IV93FXwqfilQbgWIHjWqi9pLE7dj/5aZrgTYV6Oh/zy3xlxursqdHeGkiOUugMQzB3Ewlbvq+0m8sgX9n5ZM3o7Zws/A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=ZVIK9Hxi; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=mwp84TFY; arc=none smtp.client-ip=103.168.172.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="ZVIK9Hxi"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="mwp84TFY" Received: from ams-compute-02.internal (ams-compute-02.internal [10.64.2.62]) by mailflow.phl.internal (Postfix) with ESMTP id E9CEB13800A4; Sat, 26 Sep 2026 13:14:44 -0400 (EDT) Received: from ams-imap-03 ([10.64.2.23]) by ams-compute-02.internal (MEProxy); Sat, 26 Sep 2026 13:14:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1790442884; x=1790450084; bh=tGTq2YiYGuZgWk5ZY7JZMyWu45IuuL1ykMMcgPEJafg=; b= ZVIK9Hxi8OmBYJD8gSQZXTgvlZ4ULwofUd3eHILARMayF90oSThQLlm5pu0l5+wO EnQNPrQtmiNIZnGIwOhafr8jMDFrP3Dl7gTfjveAGlyclXfQN3BLKbYH82TnwGGE LDHz+61nEQdNJ7Mm5sWNWenepLPKzpbtqHutP61oa4S7+XoKGpYriUTGoU0AgYuQ 9OTwRwbhibVgycEtR2pOCeqTs4FUfvkkls84aK/T+ibf6XDH5w7vKSNIGM7Ns4Te 135M6wCurb5eGsyT4wJmj9eSmNADUwntt12lTP3+ewZFA5Y2rk4HTFGRVv8Gm5J4 FYdUPsr/YYOVOuEmK403CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1790442884; x= 1790450084; bh=tGTq2YiYGuZgWk5ZY7JZMyWu45IuuL1ykMMcgPEJafg=; b=m wp84TFYHlBmHy48WpU0OJv+UejeKBnb6WEhb5BMBbjPw/UCY7uqA+43EKIRDaLxu G1ME4E65zZTTM83OGQxFYEaX8IjFcTplRfJNXnDCcf7M4LwptgYoomz5Pd8yjegu vxxY9CLa8ktV+zIhtoRoAiwaeH8imBZgq5qItAjTqRNlGb0cSk9vAwm0npDwQJxc ZBSOWP/LIH26Up0NfHDTJ2s5vjKd+KXmqqu3dQNyzUjNXLWwkQPUdw7wFwNq/2No YsWwT9G3+rtA9dRodWihaGIftDwTqZDbktrxc69FY4uf2b4Ufj3bOnrmH4U90eCu jkII0jgJplt+Ho3eCclLA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFhx2cFFtNhkULYuqPvl8gGeJkM2fhMBUUfWVg74H8MxuoOHs6J8LEQB/SWwobSXF cN3Bm393pJVl8n+wel7ooQQNi4RqB/GFQKqP4KFWek4N9ELRDdYFOjuVinSGdMSTiVarKs 4rOSnFGMqI3VdSxqJCmbjwz8JsjadS6g8WVg1FSsOASQL9qnvW06scsM7DdiXuQXSRvbp0 oc1rMfdDSdXjZDuQ4Flc3WgW80v1q7p36oNIX1c572OX8QvM44FF244YDOCuvYk1zcB+Fz OcU5GlcEjMBRQT8ozzGGB17lMhu1hmoOmo2ETYbYqG7qYCuz/Gp8fIl3AA5CvGes553OYH zOP0t/bzfIhWaCPZjluKxSSoXuDxxjcXX/Q8DMMxmDbQWJ9Fr5WThqDq2FLaU+SqnaJuCL pkYbhniVBzMm7pvuYCl/qtichaoaEjJr59rIk6FGTSg9hy5MSJhlHhPKI2TiyHW60MEHdl JWno9EOAuEBSzEKX+LMbGzYracPdYAHxU3uanBYFvpgh22w5H+sisOsx1bppU4jaCs1GSb qD7s7IdOD1fMrVJxaXNIjxEhMdeQ0eT9oEzd23eeqQJ6pu7bYb2KG7Sxf3YtlsvQWzwwTb DVHLWbQk3RKB8mG01KIcI+VKbYDfnxSRmys1tgvRg1CtY/krP0JQij7af/2Q X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.ams.internal (Postfix, from userid 501) id 7CCAA32A0087; Sat, 26 Sep 2026 13:14:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AJwEWD5WPnhk Date: Sat, 26 Sep 2026 19:14:14 +0200 From: "Arnd Bergmann" To: "Lorenzo Stoakes" Cc: "Andrew Morton" , "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , "Jann Horn" , "Pedro Falcato" , "David Hildenbrand (Red Hat)" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Jonathan Corbet" , "Greg Kroah-Hartman" , "Dennis Dalessandro" , "Jason Gunthorpe" , "Leon Romanovsky" , "Paul Moore" , "Stephen Smalley" , "Jaroslav Kysela" , "Takashi Iwai" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Zi Yan" , "Baolin Wang" , "Nico Pache" , "Ryan Roberts" , "Dev Jain" , "Barry Song" , "Lance Yang" , "Usama Arif" , "Kirill A. Shutemov" , "Doug Gilbert" , "James E . J . Bottomley" , "Martin K. Petersen" , "Jaya Kumar" , "Simona Vetter" , "Helge Deller" , "Sebastian Reichel" , "John Hubbard" , peterx , "Masami Hiramatsu" , "Oleg Nesterov" , "Peter Zijlstra" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, "Arnaldo Carvalho de Melo" , "Namhyung Kim" , "Mark Rutland" , "Rik van Riel" , "Harry Yoo" , "Juri Lelli" , "Vincent Guittot" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "Dave Airlie" , "Will Deacon" , "Aneesh Kumar K.V (Arm)" , "Nicholas Piggin" , "Muchun Song" , "Oscar Salvador" , "Matthew Wilcox" , "Jan Kara" , "Marc Zyngier" , "Oliver Upton" , "Catalin Marinas" , "Madhavan Srinivasan" , "Anup Patel" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Christian Borntraeger" , "Janosch Frank" , "Claudio Imbrenda" , "Alexander Gordeev" , "Gerald Schaefer" , "Heiko Carstens" , "Vasily Gorbik" , "David S . Miller" , "Andreas Larsson" , "Alexander Viro" , "Christian Brauner" , "Matthew Brost" , "Joshua Hahn" , "Rakie Kim" , "Byungchul Park" , "Gregory Price" , "Ying Huang" , "Alistair Popple" , "Chris Li" , "Kairui Song" , "Kemeng Shi" , "Nhat Pham" , "Baoquan He" , "Youngjun Park" , "Johannes Weiner" , "Qi Zheng" , "Shakeel Butt" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , "Chengming Zhou" , "Michal Hocko" , "Miklos Szeredi" , "Xu Xin" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-usb@vger.kernel.org, linux-rdma@vger.kernel.org, selinux@vger.kernel.org, linux-sound@vger.kernel.org, bpf@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Linux-Arch , linux-fsdevel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, fuse-devel@lists.linux.dev, "Takashi Iwai" , "Emil Tsalapatis" Message-Id: <4a3a089c-3ade-494d-8f83-f9cb710e9ad1@app.fastmail.com> In-Reply-To: References: <20260917-b4-mmap-prepare-vma-flag-sanify-v3-0-4583d8a23bca@kernel.org> <408aef6e-5b0a-482f-8ba8-f8c20ee870e5@app.fastmail.com> Subject: Re: [PATCH v3 00/40] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, Sep 26, 2026, at 15:22, Lorenzo Stoakes (ARM) wrote: > On Sat, Sep 26, 2026 at 03:06:33PM +0200, Arnd Bergmann wrote: >> >> It's a Kconfig setting upstream, but the way I'm doing it is to have >> patch that calculates a sensible default based on other options that >> is a little smaller than the default (currently 2048 bytes) on x86-64 >> to catch more cases where something sticks out. > > So this is an early warning more or less :) Yes, a surprising number of these just point to stupid mistakes where the developer had no they were adding a large object to the stack. This instance here is unfortunately not an obvious case. >> There are many ways the call chain can go of course, but the actual >> stack overflows do tend to follow this pattern where you are at a >> function with high stack usage and call kmalloc() during low memory >> condition and that ends up waiting for a block I/O down the line. >> (you normally don't go through swap and nfs, I was just looking >> for the worst case I could easily see in the code) > > You certainly found quite the example haha. I have previously toyed around with using VMALLOC_STACK on a reduced stack size and syzcaller, so I knew roughly where the worst offenders lie, but the list was from looking through the code just today. >> > If I can do it as a follow-up that'd be ideal! >> >> What I was hoping for is that as you are already deep into the >> exact code that caused the warning and you can already see something >> in there that may help. >> >> I don't think it's urgent, I just don't want it to be forgotten. > > It won't be, it's now on my TODO and I see it as a relatively high priority > thing to follow up with. > > Will likely send a patch for it next cycle (this is about the worst cycle I've > seen workload-size for mm so I don't really want to send anything more this time > around). Sounds good, I'll keep the local hack to mark functions as noinline for the moment then. Thanks, Arnd