lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8198558c-55f0-0ea3-3a23-e3dafb2cb09d@infradead.org>
Date:   Sat, 14 Nov 2020 09:27:16 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Matthieu Baerts <matthieu.baerts@...sares.net>,
        linux-kernel@...r.kernel.org
Cc:     kernel test robot <lkp@...el.com>,
        Aleksandr Nogikh <nogikh@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, linux-next@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: linux/skbuff.h: combine NET + KCOV handling

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ