Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
the header linux/types.h. Including it directly on the top level helps
to avoid potential problems if linux/types.h hasn't been included
before.
Signed-off-by: Dmitrii Bundin <[email protected]>
---
include/linux/btf_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
index e24aabfe8ecc..c0e3e1426a82 100644
--- a/include/linux/btf_ids.h
+++ b/include/linux/btf_ids.h
@@ -3,6 +3,8 @@
#ifndef _LINUX_BTF_IDS_H
#define _LINUX_BTF_IDS_H
+#include <linux/types.h> /* for u32 */
+
struct btf_id_set {
u32 cnt;
u32 ids[];
--
2.34.1
please use '[PATCH bpf-next]' in subject
On Sun, Apr 14, 2024 at 07:51:24AM +0300, Dmitrii Bundin wrote:
> Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> the header linux/types.h. Including it directly on the top level helps
> to avoid potential problems if linux/types.h hasn't been included
> before.
>
> Signed-off-by: Dmitrii Bundin <[email protected]>
> ---
> include/linux/btf_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index e24aabfe8ecc..c0e3e1426a82 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -3,6 +3,8 @@
> #ifndef _LINUX_BTF_IDS_H
> #define _LINUX_BTF_IDS_H
>
> +#include <linux/types.h> /* for u32 */
lgtm, did it actualy cause problem anywhere?
there's also tools/include/linux/btf_ids.h
jirka
> +
> struct btf_id_set {
> u32 cnt;
> u32 ids[];
> --
> 2.34.1
>
Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
the header linux/types.h. Including it directly on the top level helps
to avoid potential problems if linux/types.h hasn't been included
before.
Signed-off-by: Dmitrii Bundin <[email protected]>
---
Changes in v2: Add bpf-next to the subject
include/linux/btf_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
index e24aabfe8ecc..c0e3e1426a82 100644
--- a/include/linux/btf_ids.h
+++ b/include/linux/btf_ids.h
@@ -3,6 +3,8 @@
#ifndef _LINUX_BTF_IDS_H
#define _LINUX_BTF_IDS_H
+#include <linux/types.h> /* for u32 */
+
struct btf_id_set {
u32 cnt;
u32 ids[];
--
2.34.1
On Mon, Apr 15, 2024 at 3:11 PM Jiri Olsa <[email protected]> wrote:
> lgtm, did it actualy cause problem anywhere?
>
> there's also tools/include/linux/btf_ids.h
It caused the problems exactly in the file
tools/include/linux/btf_ids.h and was reported in
https://bugzilla.kernel.org/show_bug.cgi?id=218647
The patch including linux/types.h in tools/include/linux/btf_ids.h is
already there https://lore.kernel.org/all/[email protected]/
I also faced the same compile-error of the form
error: unknown type name 'u32'
u32 cnt;
^~~
when compiling the bpf tool with glibc 2.28.
I think it might be reasonable to add the inclusion in
include/linux/btf_ids.h as well to prevent build problems like this.
On Tue, Apr 16, 2024 at 08:15:27AM +0300, Dmitrii Bundin wrote:
> Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> the header linux/types.h. Including it directly on the top level helps
> to avoid potential problems if linux/types.h hasn't been included
> before.
>
> Signed-off-by: Dmitrii Bundin <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
jirka
> ---
>
> Changes in v2: Add bpf-next to the subject
>
> include/linux/btf_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index e24aabfe8ecc..c0e3e1426a82 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -3,6 +3,8 @@
> #ifndef _LINUX_BTF_IDS_H
> #define _LINUX_BTF_IDS_H
>
> +#include <linux/types.h> /* for u32 */
> +
> struct btf_id_set {
> u32 cnt;
> u32 ids[];
> --
> 2.34.1
>
On Tue, Apr 16, 2024 at 08:27:21AM +0300, Dmitrii Bundin wrote:
> On Mon, Apr 15, 2024 at 3:11 PM Jiri Olsa <[email protected]> wrote:
> > lgtm, did it actualy cause problem anywhere?
> >
> > there's also tools/include/linux/btf_ids.h
>
> It caused the problems exactly in the file
> tools/include/linux/btf_ids.h and was reported in
> https://bugzilla.kernel.org/show_bug.cgi?id=218647
> The patch including linux/types.h in tools/include/linux/btf_ids.h is
> already there https://lore.kernel.org/all/[email protected]/
> I also faced the same compile-error of the form
>
> error: unknown type name 'u32'
> u32 cnt;
> ^~~
> when compiling the bpf tool with glibc 2.28.
>
> I think it might be reasonable to add the inclusion in
> include/linux/btf_ids.h as well to prevent build problems like this.
ok, it's in the bpf/master already
jirka
On 4/16/24 9:28 AM, Jiri Olsa wrote:
> On Tue, Apr 16, 2024 at 08:27:21AM +0300, Dmitrii Bundin wrote:
>> On Mon, Apr 15, 2024 at 3:11 PM Jiri Olsa <[email protected]> wrote:
>>> lgtm, did it actualy cause problem anywhere?
>>>
>>> there's also tools/include/linux/btf_ids.h
>>
>> It caused the problems exactly in the file
>> tools/include/linux/btf_ids.h and was reported in
>> https://bugzilla.kernel.org/show_bug.cgi?id=218647
>> The patch including linux/types.h in tools/include/linux/btf_ids.h is
>> already there https://lore.kernel.org/all/[email protected]/
>> I also faced the same compile-error of the form
>>
>> error: unknown type name 'u32'
>> u32 cnt;
>> ^~~
>> when compiling the bpf tool with glibc 2.28.
>>
>> I think it might be reasonable to add the inclusion in
>> include/linux/btf_ids.h as well to prevent build problems like this.
>
> ok, it's in the bpf/master already
Please add the error description as motivation aka "why" into the commit
description, otherwise it's not really obvious looking at it at a later
point in time why the include was needed.
Thanks,
Daniel
On Tue, Apr 16, 2024 at 5:47 PM Daniel Borkmann <[email protected]> wrote:
> Please add the error description as motivation aka "why" into the commit
> description, otherwise it's not really obvious looking at it at a later
> point in time why the include was needed.
Doesn't the comment /* for u32 */ following the include explain the
purpose? I thought the include was actually missing since relying on
indirect declaration of u32 is relatively fragile.
On Wed, Apr 17, 2024 at 09:26:03AM +0300, Dmitrii Bundin wrote:
> On Tue, Apr 16, 2024 at 5:47 PM Daniel Borkmann <[email protected]> wrote:
> > Please add the error description as motivation aka "why" into the commit
> > description, otherwise it's not really obvious looking at it at a later
> > point in time why the include was needed.
>
> Doesn't the comment /* for u32 */ following the include explain the
> purpose? I thought the include was actually missing since relying on
> indirect declaration of u32 is relatively fragile.
I think you can add similar descirption as for the already merged tool
change in bpf/master, and also include the Fixes/stable tags
commit 62248b22d01e96a4d669cde0d7005bd51ebf9e76
Author: Natanael Copa <[email protected]>
Date: Thu Mar 28 11:59:13 2024 +0100
tools/resolve_btfids: fix build with musl libc
Include the header that defines u32.
This fixes build of 6.6.23 and 6.1.83 kernels for Alpine Linux, which
uses musl libc. I assume that GNU libc indirecly pulls in linux/types.h.
Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218647
Cc: [email protected]
Signed-off-by: Natanael Copa <[email protected]>
Tested-by: Greg Thelen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
jirka
Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
the header linux/types.h. Including it directly on the top level helps
to avoid potential problems if linux/types.h hasn't been included
before.
The main motiviation to introduce this it is to avoid similar problems that
was shown up in the bpf tool where GNU libc indirectly pulls
linux/types.h causing compile error of the form:
error: unknown type name 'u32'
u32 cnt;
^~~
The bpf tool compile error was fixed at 62248b22d01e96a4d669cde0d7005bd51ebf9e76
Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
Signed-off-by: Dmitrii Bundin <[email protected]>
---
Changes in v2: Add bpf-next to the subject
Changes in v3: Add Fixes tag and bpf tool commit reference
include/linux/btf_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
index e24aabfe8ecc..c0e3e1426a82 100644
--- a/include/linux/btf_ids.h
+++ b/include/linux/btf_ids.h
@@ -3,6 +3,8 @@
#ifndef _LINUX_BTF_IDS_H
#define _LINUX_BTF_IDS_H
+#include <linux/types.h> /* for u32 */
+
struct btf_id_set {
u32 cnt;
u32 ids[];
--
2.34.1
On 4/20/24 6:24 AM, Dmitrii Bundin wrote:
> Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> the header linux/types.h. Including it directly on the top level helps
> to avoid potential problems if linux/types.h hasn't been included
> before.
>
> The main motiviation to introduce this it is to avoid similar problems that
nit: spelling
> was shown up in the bpf tool where GNU libc indirectly pulls
> linux/types.h causing compile error of the form:
>
> error: unknown type name 'u32'
> u32 cnt;
> ^~~
>
> The bpf tool compile error was fixed at 62248b22d01e96a4d669cde0d7005bd51ebf9e76
>
> Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
>
> Signed-off-by: Dmitrii Bundin <[email protected]>
> ---
>
> Changes in v2: Add bpf-next to the subject
> Changes in v3: Add Fixes tag and bpf tool commit reference
>
> include/linux/btf_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index e24aabfe8ecc..c0e3e1426a82 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -3,6 +3,8 @@
> #ifndef _LINUX_BTF_IDS_H
> #define _LINUX_BTF_IDS_H
>
> +#include <linux/types.h> /* for u32 */
> +
> struct btf_id_set {
> u32 cnt;
> u32 ids[];
>
Lgtm, not sure if its worth it but also doesn't hurt and aligns the header
from tooling a bit closer to the kernel one. Just to clarify, this does not
fix a concrete issue today, so small 'cleanup' rather than 'fix'.
Thanks,
Daniel
On Fri, Apr 26, 2024 at 8:54 AM Daniel Borkmann <[email protected]> wrote:
>
> On 4/20/24 6:24 AM, Dmitrii Bundin wrote:
> > Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> > the header linux/types.h. Including it directly on the top level helps
> > to avoid potential problems if linux/types.h hasn't been included
> > before.
> >
> > The main motiviation to introduce this it is to avoid similar problems that
>
> nit: spelling
>
> > was shown up in the bpf tool where GNU libc indirectly pulls
> > linux/types.h causing compile error of the form:
> >
> > error: unknown type name 'u32'
> > u32 cnt;
> > ^~~
> >
> > The bpf tool compile error was fixed at 62248b22d01e96a4d669cde0d7005bd51ebf9e76
> >
> > Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h")
> >
> > Signed-off-by: Dmitrii Bundin <[email protected]>
> > ---
> >
> > Changes in v2: Add bpf-next to the subject
> > Changes in v3: Add Fixes tag and bpf tool commit reference
> >
> > include/linux/btf_ids.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> > index e24aabfe8ecc..c0e3e1426a82 100644
> > --- a/include/linux/btf_ids.h
> > +++ b/include/linux/btf_ids.h
> > @@ -3,6 +3,8 @@
> > #ifndef _LINUX_BTF_IDS_H
> > #define _LINUX_BTF_IDS_H
> >
> > +#include <linux/types.h> /* for u32 */
> > +
> > struct btf_id_set {
> > u32 cnt;
> > u32 ids[];
> >
>
> Lgtm, not sure if its worth it but also doesn't hurt and aligns the header
> from tooling a bit closer to the kernel one. Just to clarify, this does not
> fix a concrete issue today, so small 'cleanup' rather than 'fix'.
>
Adjusted commit message and pushed to bpf-next, thanks.
> Thanks,
> Daniel
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <[email protected]>:
On Sat, 20 Apr 2024 07:24:57 +0300 you wrote:
> Inclusion of the header linux/btf_ids.h relies on indirect inclusion of
> the header linux/types.h. Including it directly on the top level helps
> to avoid potential problems if linux/types.h hasn't been included
> before.
>
> The main motiviation to introduce this it is to avoid similar problems that
> was shown up in the bpf tool where GNU libc indirectly pulls
> linux/types.h causing compile error of the form:
>
> [...]
Here is the summary with links:
- [bpf-next,v3] bpf: btf: include linux/types.h for u32
https://git.kernel.org/bpf/bpf-next/c/cfd3bfe9507b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html