Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4469054pxf; Tue, 16 Mar 2021 14:29:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydj+YwxcNBXT0U5+xHRwrLQP8BTFIcZc+QalYWdEspCjT3g8I3y8uHuASutqdDLpCJkUQP X-Received: by 2002:a17:906:86c1:: with SMTP id j1mr32930102ejy.373.1615930143122; Tue, 16 Mar 2021 14:29:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615930143; cv=none; d=google.com; s=arc-20160816; b=PS1SJAXDVvx+ss1l+C1tUXWZldkeW50EnzU1Nqq3VU+zOlxKJgnTdrrBoLr0nYxcaX 0N+LFPQJv72yhhQGFOSlw0rRf/paKx9gyjk/6PvJ+25cf0M+hbj7WNKdJURG3aRDTUZ0 OBjqhV7OhmlomcuKextoDOnzDJgx8bZuYbz9a3P3h1inJahLOoJH8XIMSsDT9WlYUMek jt06AbWI0ZpbLXkY4E7b9UIJarxUtT5mR4McYB0lmhHWXZWhD4Nsq3ToRKCnIGaoc2NU iGzwNMuT97PbDpYVc/Ui9PDG9eaISP49tCiPeOJw7vkvprG4or0XsS/ZelWNOxFiTD5l P+xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=9j/6hBpxYn36SrqleC0WR/Asrgq0BJhWFdV+yuWTqqI=; b=xzETMOg95i5jR6cnODPw+oBJBTvEPMji/2efgbu/TIJ56ld5MqTEWgiBnxM1aoam8z 82Z0A71/6ABTwxhTcek/fkAT/xYyxVLPAIKzgcQ65zwmHZjvDOnLPLc6oa/WqAA+WjWY t7CKLnncObsbP5oNs3HfWdmWlaYBNblzCtL3wjuklovd7K4HaLfqx1wPgwqchFYTpOYI Du7cL+4g2aY01Sryq5KPZk9JzbsqPQfZZX2Aen36+tfGdeC8mQuWE/9+U5s5Bv4Xmuky ZKCrpqKwy7XYYb/wvm6iWwUpecpGEiJZ080zj7niNjJ0eOMe4NBhNsfjwWXpvKbadmWS 0ESQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p16si14592002edu.606.2021.03.16.14.28.41; Tue, 16 Mar 2021 14:29:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232260AbhCPVBx (ORCPT + 99 others); Tue, 16 Mar 2021 17:01:53 -0400 Received: from www62.your-server.de ([213.133.104.62]:59966 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232211AbhCPVBp (ORCPT ); Tue, 16 Mar 2021 17:01:45 -0400 Received: from sslproxy03.your-server.de ([88.198.220.132]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lMGov-000DD5-8i; Tue, 16 Mar 2021 22:01:41 +0100 Received: from [85.7.101.30] (helo=pc-9.home) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lMGou-000NvJ-VU; Tue, 16 Mar 2021 22:01:40 +0100 Subject: Re: [PATCH] libbpf: avoid inline hint definition from 'linux/stddef.h' To: Pedro Tammela Cc: Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Nathan Chancellor , Nick Desaulniers , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com References: <20210314173839.457768-1-pctammela@gmail.com> From: Daniel Borkmann Message-ID: <5083f82b-39fc-9d46-bcd0-3a6be2fc7f98@iogearbox.net> Date: Tue, 16 Mar 2021 22:01:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20210314173839.457768-1-pctammela@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.4/26110/Tue Mar 16 12:05:23 2021) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/14/21 6:38 PM, Pedro Tammela wrote: > Linux headers might pull 'linux/stddef.h' which defines > '__always_inline' as the following: > > #ifndef __always_inline > #define __always_inline __inline__ > #endif > > This becomes an issue if the program picks up the 'linux/stddef.h' > definition as the macro now just hints inline to clang. How did the program end up including linux/stddef.h ? Would be good to also have some more details on how we got here for the commit desc. > This change now enforces the proper definition for BPF programs > regardless of the include order. > > Signed-off-by: Pedro Tammela > --- > tools/lib/bpf/bpf_helpers.h | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h > index ae6c975e0b87..5fa483c0b508 100644 > --- a/tools/lib/bpf/bpf_helpers.h > +++ b/tools/lib/bpf/bpf_helpers.h > @@ -29,9 +29,12 @@ > */ > #define SEC(NAME) __attribute__((section(NAME), used)) > > -#ifndef __always_inline > +/* > + * Avoid 'linux/stddef.h' definition of '__always_inline'. > + */ I think the comment should have more details on 'why' we undef it as in few months looking at it again, the next question to dig into would be what was wrong with linux/stddef.h. Providing a better rationale would be nice for readers here. > +#undef __always_inline > #define __always_inline inline __attribute__((always_inline)) > -#endif > + > #ifndef __noinline > #define __noinline __attribute__((noinline)) > #endif >