From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A93DB3BFE25 for ; Mon, 29 Jun 2026 19:43:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782762234; cv=none; b=F4AEr6Ng19IIGuLLVNLyYlNEPbbJTKtskqL99sc/AAqFg82KiuOOLo3epKQ+vsKQWOKf5ZG8zqhJQaZBGKL9/Kj9Ou5oLfvUstMNIiRNfsPKeM/A0XFeOr4FfXlGrynOTWlTIXlq3Wc48t4uyjgKH6t+Lujxp71moWqWoFQFe9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782762234; c=relaxed/simple; bh=KYM91xn93M0K3mj9Kdu5chGwtMFHVmsWiOZkyC0Yekk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=csAJQcXv0P3zG57h78+U6225fvt2A/ruUnAqoDXAswXAs3tOuM+R8CAiwrj3bM1IDYpjjuKW2ptxJahuusse8pAEjmeovjQ/aS2f7GCeCmgiZDe2RaKa+6M+UVQ/vTbZNODFzQX/BD/zkC9W6gDelNDetIivP7dpjmb3zOKIdIc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=q7mp1Iqg; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="q7mp1Iqg" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-4703bc0a99aso1362521f8f.3 for ; Mon, 29 Jun 2026 12:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782762231; x=1783367031; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YpO9o8eBWwEDpQBKixvSvSC+ysdTw08zIfmp92hvBSs=; b=q7mp1IqgrDDOT0UhuOUQjG+RrPKcn3UapGpmk8p4QgUD+JHvCC0TJNMjIIvKx+pkU7 kUqjCbOGmsB5sAejvgnzZKlYNnNRhi4SQnnsTr8C8nFEFzdccLa7zTrTDO2sfg0mBxM7 cdPLC+zFXLS+FhYDywuLqhGoQXpR6oqWDLLO/BZsAa154lJmv64gIzoRwGutr7FwFWWH qJsHZ4VLY9v8YhgBJoecuPdUBTVQcdl1rTIah4ZwIV3qsnIWaXxU9xbTsaT3A50lP8wQ 30JfFB43/E9ZrQ3YzXGMG88J8gR2vzOpqLR85JoqMLwiMuYfrxhB2cxVsk0o5mdrpnVn jF0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782762231; x=1783367031; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YpO9o8eBWwEDpQBKixvSvSC+ysdTw08zIfmp92hvBSs=; b=JeHyIq48woeUkQKg958KZ0/ExUH6HKTTeZcIEJh4MFI5M3rMxDrY/goRlHegsao7X9 WkV+ozxoIb6T8/Bo/axVOU6scfcUsZoSUuYKMbXjYOuuh2Q/VeCHLgLOfMaXEdfSp7ZN bUv0qa8bJgJFUjZx2rJIrIkj+kEXtNnK0t+3QB+hNc7hPK3pUWHmxIxZ0UbavAgbLE0b z9TzPRrE5bInmz939TxdxkXaq15ik6Zq/JpdR5A85vthOh98DR8ycErnaW1sKi7a2nUD AGY7/gPyZtMIasK0H6Ey47PxRhDzM4XPXUAq7wrH7jOZtdCs/TjfvWWixtpiu7vhE4jY pL0Q== X-Forwarded-Encrypted: i=1; AFNElJ/w0sf7B8aJd++1LCFeIOdEme1mzB0S2zrLqVpekxzTzzqBA2Gor2Y7heuddBsm/uhNNvXKjcEixIubllU=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4j1Ga8Uzsv9WnEqH37VFNpo5mDEe0uhMZ4EYs6GCsBipMTKIE fwklAoP7Rd7Ah0mdybYZE0rxQ7zf1P8pIEYYd8kJunUXVtBd6WPEJcyz X-Gm-Gg: AfdE7cmoaIGPMMFlvLA/9RWGQfQ3hZmr9NxidzyQXUYEz22jsUvyzChm5kCO+PGHDmW 0zmpnVw1aY0nPAQrrcX1AMWvaD91kIOh1tpFUjJTdZsR8xiVe7hbCDibnzsLz6RBARZLeEW4QW3 BPxfqit9CUQaT6vjnFddLkv0hGB2IQUv5TxYolNnPhigU5SyFJ358aikGyDNSxc8Csoq0Z50SQa fG7jcfnUkBkWFxhNf4XRs+tGWMCWI8AgOG1nQxNk7MqCYDxYKzE2LThyu8Dg8elMJIutRs7cBfp wtiM8JrmivLdtuVMZ81JYccoytD59azTEhQHlGYX+tywZcKzzMuV22warkgFemybU8QdeBKn2eu CAstyXMHs5D39j1Pdjl73Kxvzs6oH7Rkd1WEPwDsFoGFir//dKxCsO9XivLmE4sruAgj/DehIbc H5xk1xOAzaO5gp1KVQ06gZeCiwB3s+NZaaKAIUhRqMwRadog== X-Received: by 2002:a05:600c:216:b0:492:67df:3dfa with SMTP id 5b1f17b1804b1-493b82c5c25mr11631265e9.34.1782762230853; Mon, 29 Jun 2026 12:43:50 -0700 (PDT) Received: from pumpkin (host-92-21-50-228.as13285.net. [92.21.50.228]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493b8ca8b1csm9654695e9.9.2026.06.29.12.43.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 12:43:50 -0700 (PDT) Date: Mon, 29 Jun 2026 20:43:48 +0100 From: David Laight To: "Zach O'Keefe" Cc: "H. Peter Anvin" , "Vlastimil Babka (SUSE)" , Dave Hansen , Thomas Gleixner , David Stevens , Pasha Tatashin , Linus Walleij , Will Deacon , Quentin Perret , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Andy Lutomirski , Xin Li , Peter Zijlstra , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Uladzislau Rezki , Kees Cook , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 00/13] Dynamic Kernel Stacks Message-ID: <20260629204348.2426a800@pumpkin> In-Reply-To: References: <20260424191456.2679717-1-stevensd@google.com> <6369e5ce-74e3-4c68-8053-d7d7d21b6955@zytor.com> <87pl1md7h0.ffs@fw13> <87qzm2b39k.ffs@fw13> <87mrwon5uw.ffs@fw13> <87cxxgly12.ffs@fw13> <5604a47b-9457-4162-bd23-720e29cf1983@intel.com> <37a630ef-1574-4415-b42c-1d23993c6084@zytor.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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, 29 Jun 2026 10:29:53 -0700 "Zach O'Keefe" wrote: > Thanks All. > > Yes, we run with CONFIG_DEBUG_STACK_USAGE -- which allows us to put > together information on max stack depth usage per host/task. > > I'd like to create an upstream recipe for finding deep stacks > statically by combining per-frame sizes from --fstack-usage with > callgraphs generated using Dan Carpenter's smatch utility. In > particular, smatch's selling point is the ability to track indirect > calls (i.e., calls through vm_operations, super_operations, etc). > While easy to set up, and working well out-of-the-box, this currently > results in many false-positive callstack possibilities, so I'm trying > to pare down the graph to get to some useable data. Additionally will > need to know what exception-originating stacks can possibly be > superimposed on the base callstack, for the given configuration -- for > example, today, only a few places we'd expect to see #PF stack. > Lastly, I've been analyzing perf-like data to authoritatively > construct the call graphs as well -- or at least to use for > seeding/filtering the static call graph. I've thought of trying to do that getting objtool to output the stack offset of every call (I think it ends up in the debug info) and using the IBT function hashes to group indirect calls together. But I've not got further than failing to compile a kernel with the required compiler options :-( Unravelling the mess and breaking recursive call loops is a separate problem - which you seem to have hit. (I've done it many, many years ago for an embedded system with no indirect calls of recursion.) I think objtool already works out a lot of things you'd need. Getting it to output a file of: 'func_x at stack offset off calls func_y' would give something to post-process. David > > Thanks, > Zach >