public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Menglong Dong <menglong8.dong@gmail.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	kuba@kernel.org, miguel.ojeda.sandonis@gmail.com,
	ojeda@kernel.org, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, asml.silence@gmail.com, imagedong@tencent.com,
	luiz.von.dentz@intel.com, vasily.averin@linux.dev,
	jk@codeconstruct.com.au, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, kernel test robot <lkp@intel.com>,
	linux-toolchains <linux-toolchains@vger.kernel.org>
Subject: Re: [PATCH net-next v4] net: skb: prevent the split of kfree_skb_reason() by gcc
Date: Wed, 7 Sep 2022 14:47:15 -0500	[thread overview]
Message-ID: <20220907194715.GK25951@gate.crashing.org> (raw)
In-Reply-To: <87zgfbnh81.fsf@oldenburg.str.redhat.com>

On Wed, Sep 07, 2022 at 08:59:26PM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
> 
> > On Tue, Sep 06, 2022 at 02:37:47PM +0200, Florian Weimer wrote:
> >> > On Mon, Aug 22, 2022 at 4:01 PM Florian Weimer <fweimer@redhat.com> wrote:
> >> > I did some research on the 'sibcalls' you mentioned above. Feel like
> >> > It's a little similar to 'inline', and makes the callee use the same stack
> >> > frame with the caller, which obviously will influence the result of
> >> > '__builtin_return_address'.
> >
> > Sibling calls are essentially calls that can be replaced by jumps (aka
> > "tail call"), without needing a separate entry point to the callee.
> >
> > Different targets can have a slightly different implementation and
> > definition of what exactly is a sibling call, but that's the gist.
> >
> >> > Hmm......but I'm not able to find any attribute to disable this optimization.
> >> > Do you have any ideas?
> >> 
> >> Unless something changed quite recently, GCC does not allow disabling
> >> the optimization with a simple attribute (which would have to apply to
> >> function pointers as well, not functions).
> >
> > It isn't specified what a sibling call exactly *is*, certainly not on C
> > level (only in the generated machine code), and the details differs per
> > target.
> 
> Sure, but GCC already disables this optimization in a generic fashion
> for noreturn calls.  It should be possible to do the same based another
> function attribute.

My point is that disabling sibling calls does not necessarily do what
you really want, certainly not on all targets.  Many targets have their
own frame optimisations and prologue/epilogue optimisations as well.

But you can just do
  void f(void) __attribute__((optimize("no-optimize-sibling-calls")));
(in my previous example), and that works: it disables the (generic)
sibling call optimisation.  This may or may not do what you actually
want though.


Segher

  reply	other threads:[~2022-09-07 19:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16  3:28 [PATCH net-next v4] net: skb: prevent the split of kfree_skb_reason() by gcc menglong8.dong
2022-08-16  9:02 ` Miguel Ojeda
2022-08-17  2:20   ` Menglong Dong
2022-08-17  5:54     ` Miguel Ojeda
2022-08-17 15:54 ` Nick Desaulniers
2022-08-18 16:31   ` Menglong Dong
2022-08-18 16:58     ` Segher Boessenkool
2022-08-19 14:55       ` Menglong Dong
2022-08-19 15:21         ` Segher Boessenkool
2022-08-20 11:00           ` Menglong Dong
2022-08-22  8:01             ` Florian Weimer
2022-08-23 16:23               ` Menglong Dong
2022-09-06 12:37                 ` Florian Weimer
2022-09-06 15:30                   ` Segher Boessenkool
2022-09-07 18:59                     ` Florian Weimer
2022-09-07 19:47                       ` Segher Boessenkool [this message]
2022-08-18 17:09 ` Jakub Kicinski
2022-08-19 15:17   ` Menglong Dong

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=20220907194715.GK25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=asml.silence@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fweimer@redhat.com \
    --cc=imagedong@tencent.com \
    --cc=jk@codeconstruct.com.au \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=luiz.von.dentz@intel.com \
    --cc=menglong8.dong@gmail.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vasily.averin@linux.dev \
    /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