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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9F6BC4332F for ; Wed, 13 Dec 2023 01:13:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378139AbjLMBNf (ORCPT ); Tue, 12 Dec 2023 20:13:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377653AbjLMBNe (ORCPT ); Tue, 12 Dec 2023 20:13:34 -0500 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43ED391; Tue, 12 Dec 2023 17:13:39 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CE0295C01D7; Tue, 12 Dec 2023 20:13:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 12 Dec 2023 20:13:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; 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=fm3; t=1702430016; x=1702516416; bh=q1SPQYQRBWl7bFrY5/lVAS8dc6PpLJdw7+EOXaZGVW4=; b= Ze0PwEh2S3szHV/ysnl1BX0zv1/CfSBmMStu4vXojWR8sKZ/+ev5W6PpgP4i1la5 INWsbQWMZOhPOPz0Ss3v6hx3aLl+r3+O7DNtSkjQ4k8b0BSpKudqERUpkdFcwWrC u5Hb9hQrPiUyBnGaK0Mx2qM5oHX/QOJyk1ltkecAlXM1w18/xSMNTkSNkMkIcha3 aBigpGgHNFrD9s/99NM2EPyaZSFJofrufVllgbTDQD3x8agFx+uWv937VPj4yQov LDZ61yro2+0ViZyt44dv6aTAIDLwVaw48rU/G/CIczeS5MKuaFTaaici99+Hb0r9 xLoEXdf5gQQQHJmIiOrHvw== 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-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1702430016; x= 1702516416; bh=q1SPQYQRBWl7bFrY5/lVAS8dc6PpLJdw7+EOXaZGVW4=; b=2 Pu5VDvJxB+hNgOzbQS8onyFPjDTA5005w70yUaUEx6sY6LH9thUWrT74U/eM3n7i 8sPvzZT5BraMUnai4Oiurvmrz7CyvxK/uFWVESLJ0aNxBcLpSUF3XDmk7aP2wSFe LNZXNSS1TYD3y8iPrKxqQjisH5lHYJCXCy6x+x0N/zMRlDWw8x9C5TcFU4DM+/tH PndYo4EQezv+W1RekQUeHg0M/6/qxChKcZJEOev1fsqcH93x1yG6i8O6KdSKFZMA nLbYJEO7M/CxVv+30+imA2niTK7g/I3Aly/SsLJKWaZb/pE3rxn0XKizH3RhgSob DxC3cAqIgfb7dAt4xiphw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelhedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfvfevfhfhufgjtgfgsehtjeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epjeegkedvhfekueejgeefieejtdevledvtdelieevveekffejfedtvdehkeefjeeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Dec 2023 20:13:32 -0500 (EST) Message-ID: Date: Wed, 13 Dec 2023 09:13:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 To: Arnd Bergmann , Alexander Viro , Christian Brauner Cc: Arnd Bergmann , Jan Kara , Miklos Szeredi , "Seth Forshee (DigitalOcean)" , Dave Chinner , Amir Goldstein , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20231212214819.247611-1-arnd@kernel.org> Content-Language: en-US From: Ian Kent Subject: Re: [PATCH] statmount: reduce runtime stack usage In-Reply-To: <20231212214819.247611-1-arnd@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/12/23 05:48, Arnd Bergmann wrote: > From: Arnd Bergmann > > prepare_kstatmount() constructs a copy of 'struct kstatmount' on the stack > and copies it into the local variable on the stack of its caller. Because > of the size of this structure, this ends up overflowing the limit for > a single function's stack frame when prepare_kstatmount() gets inlined > and both copies are on the same frame without the compiler being able > to collapse them into one: > > fs/namespace.c:4995:1: error: stack frame size (1536) exceeds limit (1024) in '__se_sys_statmount' [-Werror,-Wframe-larger-than] > 4995 | SYSCALL_DEFINE4(statmount, const struct mnt_id_req __user *, req, > > Mark the inner function as noinline_for_stack so the second copy is > freed before calling do_statmount() enters filesystem specific code. > The extra copy of the structure is a bit inefficient, but this > system call should not be performance critical. Are you sure this is not performance sensitive, or is the performance critical comment not related to the system call being called many times? It's going to be a while (if ever) before callers change there ways. Consider what happens when a bunch of mounts are being mounted. First there are a lot of events and making the getting of mount info. more efficient means more of those events get processed (itself an issue that's going to need notification sub-system improvement) resulting in the system call being called even more. There are 3 or 4 common programs that monitor the mounts, systemd is one of those, it usually has 3 processes concurrently listening for mount table events and every one of these processes grabs the entire table. Thing is systemd is actually quite good at handling events and can process a lot of them if they are being occuring. So this system call will be called a lot. Ian > > Fixes: 49889374ab92 ("statmount: simplify string option retrieval") > Signed-off-by: Arnd Bergmann > --- > fs/namespace.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index d036196f949c..e22fb5c4a9bb 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -4950,7 +4950,8 @@ static inline bool retry_statmount(const long ret, size_t *seq_size) > return true; > } > > -static int prepare_kstatmount(struct kstatmount *ks, struct mnt_id_req *kreq, > +static int noinline_for_stack > +prepare_kstatmount(struct kstatmount *ks, struct mnt_id_req *kreq, > struct statmount __user *buf, size_t bufsize, > size_t seq_size) > {