Thread (12 messages) 12 messages, 5 authors, 2022-08-20

Re: [PATCH net-next v4] net: skb: prevent the split of kfree_skb_reason() by gcc

From: Jakub Kicinski <kuba@kernel.org>
Date: 2022-08-18 17:16:43
Also in: lkml

On Tue, 16 Aug 2022 11:28:46 +0800 menglong8.dong@gmail.com wrote:
From: Menglong Dong <redacted>

Sometimes, gcc will optimize the function by spliting it to two or
more functions. In this case, kfree_skb_reason() is splited to
kfree_skb_reason and kfree_skb_reason.part.0. However, the
function/tracepoint trace_kfree_skb() in it needs the return address
of kfree_skb_reason().

This split makes the call chains becomes:
  kfree_skb_reason() -> kfree_skb_reason.part.0 -> trace_kfree_skb()

which makes the return address that passed to trace_kfree_skb() be
kfree_skb().

Therefore, prevent this kind of optimization to kfree_skb_reason() by
making the optimize level to "O1". I think these should be better
method instead of this "O1", but I can't figure it out......

This optimization CAN happen, which depend on the behavior of gcc.
I'm not able to reproduce it in the latest kernel code, but it happens
in my kernel of version 5.4.119. Maybe the latest code already do someting
that prevent this happen?

Signed-off-by: Menglong Dong <redacted>
Reported-by: kernel test robot <redacted>
Reported-by: Miguel Ojeda <redacted>
Sorry for a late and possibly off-topic chime in, is the compiler
splitting it because it thinks that skb_unref() is going to return 
true? I don't think that's the likely case, so maybe we're better 
off wrapping that skb_unref() in unlikely()?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help