From: Boqun Feng <boqun.feng@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Waiman Long <longman@redhat.com>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] lockdep: avoid struct return in lock_stats()
Date: Wed, 18 Jun 2025 10:59:37 -0700 [thread overview]
Message-ID: <aFL-iZL467DTBj8k@tardis.local> (raw)
In-Reply-To: <aFL8i4Uraaw9390B@smile.fi.intel.com>
On Wed, Jun 18, 2025 at 08:51:07PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 17, 2025 at 10:17:32PM -0700, Boqun Feng wrote:
> > On Tue, Jun 10, 2025 at 11:29:21AM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Returning a large structure from the lock_stats() function causes clang
> > > to have multiple copies of it on the stack and copy between them, which
> > > can end up exceeding the frame size warning limit:
> > >
> > > kernel/locking/lockdep.c:300:25: error: stack frame size (1464) exceeds limit (1280) in 'lock_stats' [-Werror,-Wframe-larger-than]
> > > 300 | struct lock_class_stats lock_stats(struct lock_class *class)
> > >
> > > Change the calling conventions to directly operate on the caller's copy,
> > > which apparently is what gcc does already.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Queued for more tests and reviews, thanks!
>
> What about this one:
> lockdep: change 'static const' variables to enum values
>
> ?
>
> (I can't quickly find the pointer right now, but I think in lore.kernel.org you can find it)
>
This one:
https://lore.kernel.org/lkml/20250409122314.2848028-6-arnd@kernel.org/
? I will take a look (give me some time to learn about that compiler
option), but seems trivial enough, should be in the next merge window if
no problem found. Thanks for bringing it up.
Regards,
Boqun
> --
> With Best Regards,
> Andy Shevchenko
>
>
next prev parent reply other threads:[~2025-06-18 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 9:29 Arnd Bergmann
2025-06-18 5:17 ` Boqun Feng
2025-06-18 17:51 ` Andy Shevchenko
2025-06-18 17:59 ` Boqun Feng [this message]
2025-07-19 17:40 ` [tip: locking/core] locking/lockdep: Avoid " tip-bot2 for Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFL-iZL467DTBj8k@tardis.local \
--to=boqun.feng@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=justinstitt@google.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®