From: Randy Dunlap <rdunlap@infradead.org>
To: Matthieu Baerts <matthieu.baerts@tessares.net>,
linux-kernel@vger.kernel.org
Cc: kernel test robot <lkp@intel.com>,
Aleksandr Nogikh <nogikh@google.com>,
Willem de Bruijn <willemb@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-next@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: linux/skbuff.h: combine NET + KCOV handling
Date: Sat, 14 Nov 2020 09:27:16 -0800 [thread overview]
Message-ID: <8198558c-55f0-0ea3-3a23-e3dafb2cb09d@infradead.org> (raw)
In-Reply-To: <52502fe4-8f41-0630-5b9c-be2e07b6932c@tessares.net>
On 11/14/20 12:01 AM, Matthieu Baerts wrote:
> Hi Randy,
>
> On 14/11/2020 02:11, Randy Dunlap wrote:
>> The previous Kconfig patch led to some other build errors as
>> reported by the 0day bot and my own overnight build testing.
>
> Thank you for looking at that!
>
> I had the same issue and I was going to propose a similar fix with one small difference, please see below.
>
>> --- linux-next-20201113.orig/include/linux/skbuff.h
>> +++ linux-next-20201113/include/linux/skbuff.h
>> @@ -4608,7 +4608,7 @@ static inline void skb_reset_redirect(st
>> #endif
>> }
>> -#ifdef CONFIG_KCOV
>> +#if IS_ENABLED(CONFIG_KCOV) && IS_ENABLED(CONFIG_NET)
>> static inline void skb_set_kcov_handle(struct sk_buff *skb,
> Should we have here CONFIG_SKB_EXTENSIONS instead of CONFIG_NET?
>
> It is valid to use NET thanks to your commit 85ce50d337d1 ("net: kcov: don't select SKB_EXTENSIONS when there is no NET") that links SKB_EXTENSIONS with NET for KCOV but it looks strange to me to use a "non direct" dependence :)
> I mean: here below, skb_ext_add() and skb_ext_find() are called but they are defined only if SKB_EXTENSIONS is enabled, not only NET.
>
> But as I said, this patch fixes the issue. It's fine for me if we prefer to use CONFIG_NET.
I think it would be safer to use CONFIG_SKB_EXTENSIONS.
>> @@ -4636,7 +4636,7 @@ static inline u64 skb_get_kcov_handle(st
>> static inline void skb_set_kcov_handle(struct sk_buff *skb,
>> const u64 kcov_handle) { }
>> static inline u64 skb_get_kcov_handle(struct sk_buff *skb) { return 0; }
>> -#endif /* CONFIG_KCOV */
>> +#endif /* CONFIG_KCOV && CONFIG_NET */
>
> (Small detail if you post a v2: there is an extra space between "&&" and "CONFIG_NET")
Oops. Fixed in v2. Thanks for looking.
v2 on the way.
--
~Randy
prev parent reply other threads:[~2020-11-14 17:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 1:11 Randy Dunlap
2020-11-14 8:01 ` Matthieu Baerts
2020-11-14 17:27 ` Randy Dunlap [this message]
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=8198558c-55f0-0ea3-3a23-e3dafb2cb09d@infradead.org \
--to=rdunlap@infradead.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=lkp@intel.com \
--cc=matthieu.baerts@tessares.net \
--cc=netdev@vger.kernel.org \
--cc=nogikh@google.com \
--cc=willemb@google.com \
/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®