[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220819152157.GO25951@gate.crashing.org>
Date: Fri, 19 Aug 2022 10:21:57 -0500
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>, kuba@...nel.org,
miguel.ojeda.sandonis@...il.com, ojeda@...nel.org,
davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
asml.silence@...il.com, imagedong@...cent.com,
luiz.von.dentz@...el.com, vasily.averin@...ux.dev,
jk@...econstruct.com.au, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, kernel test robot <lkp@...el.com>,
linux-toolchains <linux-toolchains@...r.kernel.org>
Subject: Re: [PATCH net-next v4] net: skb: prevent the split of kfree_skb_reason() by gcc
Hi!
On Fri, Aug 19, 2022 at 10:55:42PM +0800, Menglong Dong wrote:
> Thanks for your explanation about the usage of 'noinline' and 'no_icf'!
> I think 'noclone' seems enough in this case? As the function
> 'kfree_skb_reason' we talk about is a global function, I think that the
> compiler has no reason to make it inline, or be merged with another
> function.
Whether something is inlined is decided per instance (except for
always_inline and noinline functions). Of course the function body has
to be available for anything to be inlined, so barring LTO this can only
happen for function uses in the same source file. Not very likely
indeed, but not entirely impossible either.
A function can be merged if there is another function that does exactly
the same thing. This is unlikely with functions that do some serious
work of course, but it is likely with stub-like functions.
gl;hf,
Segher
Powered by blists - more mailing lists