* Re: (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
[not found] <20210526080741.GW30378@techsingularity.net>
@ 2021-05-26 8:33 ` Michal Suchánek
2021-05-26 9:00 ` Mel Gorman
2021-05-26 17:00 ` Andrii Nakryiko
0 siblings, 2 replies; 4+ messages in thread
From: Michal Suchánek @ 2021-05-26 8:33 UTC (permalink / raw)
To: Mel Gorman, linux-kbuild
Cc: Andrew Morton, Andrii Nakryiko, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, open list, Arnaldo Carvalho de Melo,
Jiri Olsa, Hritik Vijay, bpf, Linux-Net, Linux-MM,
Masahiro Yamada
On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote:
> Michal Suchanek reported the following problem with linux-next
>
> [ 0.000000] Linux version 5.13.0-rc2-next-20210519-1.g3455ff8-vanilla (geeko@buildhost) (gcc (SUSE Linux) 10.3.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-3) #1 SMP Wed May 19 10:05:10 UTC 2021 (3455ff8)
> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla root=UUID=ec42c33e-a2c2-4c61-afcc-93e9527 8f687 plymouth.enable=0 resume=/dev/disk/by-uuid/f1fe4560-a801-4faf-a638-834c407027c7 mitigations=auto earlyprintk initcall_debug nomodeset earlycon ignore_loglevel console=ttyS0,115200
> ...
> [ 26.093364] calling tracing_set_default_clock+0x0/0x62 @ 1
> [ 26.098937] initcall tracing_set_default_clock+0x0/0x62 returned 0 after 0 usecs
> [ 26.106330] calling acpi_gpio_handle_deferred_request_irqs+0x0/0x7c @ 1
> [ 26.113033] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x7c returned 0 after 3 usecs
> [ 26.121559] calling clk_disable_unused+0x0/0x102 @ 1
> [ 26.126620] initcall clk_disable_unused+0x0/0x102 returned 0 after 0 usecs
> [ 26.133491] calling regulator_init_complete+0x0/0x25 @ 1
> [ 26.138890] initcall regulator_init_complete+0x0/0x25 returned 0 after 0 usecs
> [ 26.147816] Freeing unused decrypted memory: 2036K
> [ 26.153682] Freeing unused kernel image (initmem) memory: 2308K
> [ 26.165776] Write protecting the kernel read-only data: 26624k
> [ 26.173067] Freeing unused kernel image (text/rodata gap) memory: 2036K
> [ 26.180416] Freeing unused kernel image (rodata/data gap) memory: 1184K
> [ 26.187031] Run /init as init process
> [ 26.190693] with arguments:
> [ 26.193661] /init
> [ 26.195933] with environment:
> [ 26.199079] HOME=/
> [ 26.201444] TERM=linux
> [ 26.204152] BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla
> [ 26.254154] BPF: type_id=35503 offset=178440 size=4
> [ 26.259125] BPF:
> [ 26.261054] BPF:Invalid offset
> [ 26.264119] BPF:
> [ 26.264119]
> [ 26.267437] failed to validate module [efivarfs] BTF: -22
>
> Andrii Nakryiko bisected the problem to the commit "mm/page_alloc: convert
> per-cpu list protection to local_lock" currently staged in mmotm. In his
> own words
>
> The immediate problem is two different definitions of numa_node per-cpu
> variable. They both are at the same offset within .data..percpu ELF
> section, they both have the same name, but one of them is marked as
> static and another as global. And one is int variable, while another
> is struct pagesets. I'll look some more tomorrow, but adding Jiri and
> Arnaldo for visibility.
>
> [110907] DATASEC '.data..percpu' size=178904 vlen=303
> ...
> type_id=27753 offset=163976 size=4 (VAR 'numa_node')
> type_id=27754 offset=163976 size=4 (VAR 'numa_node')
>
> [27753] VAR 'numa_node' type_id=27556, linkage=static
> [27754] VAR 'numa_node' type_id=20, linkage=global
>
> [20] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
>
> [27556] STRUCT 'pagesets' size=0 vlen=1
> 'lock' type_id=507 bits_offset=0
>
> [506] STRUCT '(anon)' size=0 vlen=0
> [507] TYPEDEF 'local_lock_t' type_id=506
>
> The patch in question introduces a zero-sized per-cpu struct and while
> this is not wrong, versions of pahole prior to 1.22 (unreleased) get
> confused during BTF generation with two separate variables occupying the
> same address.
>
> This patch checks for older versions of pahole and forces struct pagesets
> to be non-zero sized as a workaround when CONFIG_DEBUG_INFO_BTF is set. A
> warning is omitted so that distributions can update pahole when 1.22
> is released.
>
> Reported-by: Michal Suchanek <msuchanek@suse.de>
> Reported-by: Hritik Vijay <hritikxx8@gmail.com>
> Debugged-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> ---
> lib/Kconfig.debug | 3 +++
> mm/page_alloc.c | 11 +++++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 678c13967580..f88a155b80a9 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -313,6 +313,9 @@ config DEBUG_INFO_BTF
> config PAHOLE_HAS_SPLIT_BTF
> def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
>
> +config PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT
> + def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "122")
> +
This does not seem workable with dummy-tools.
Do we even have dummy pahole?
Thanks
Michal
> config DEBUG_INFO_BTF_MODULES
> def_bool y
> depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ff8f706839ea..1d56d3de8e08 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -124,6 +124,17 @@ static DEFINE_MUTEX(pcp_batch_high_lock);
>
> struct pagesets {
> local_lock_t lock;
> +#if defined(CONFIG_DEBUG_INFO_BTF) && \
> + !defined(CONFIG_DEBUG_LOCK_ALLOC) && \
> + !defined(CONFIG_PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT)
> + /*
> + * pahole 1.21 and earlier gets confused by zero-sized per-CPU
> + * variables and produces invalid BTF. Ensure that
> + * sizeof(struct pagesets) != 0 for older versions of pahole.
> + */
> + char __pahole_hack;
> + #warning "pahole too old to support zero-sized struct pagesets"
> +#endif
> };
> static DEFINE_PER_CPU(struct pagesets, pagesets) = {
> .lock = INIT_LOCAL_LOCK(lock),
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
2021-05-26 8:33 ` (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Michal Suchánek
@ 2021-05-26 9:00 ` Mel Gorman
2021-05-26 17:00 ` Andrii Nakryiko
1 sibling, 0 replies; 4+ messages in thread
From: Mel Gorman @ 2021-05-26 9:00 UTC (permalink / raw)
To: Michal Such?nek
Cc: linux-kbuild, Andrew Morton, Andrii Nakryiko, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, open list, Arnaldo Carvalho de Melo,
Jiri Olsa, Hritik Vijay, bpf, Linux-Net, Linux-MM,
Masahiro Yamada
On Wed, May 26, 2021 at 10:33:42AM +0200, Michal Such?nek wrote:
> > lib/Kconfig.debug | 3 +++
> > mm/page_alloc.c | 11 +++++++++++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 678c13967580..f88a155b80a9 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -313,6 +313,9 @@ config DEBUG_INFO_BTF
> > config PAHOLE_HAS_SPLIT_BTF
> > def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
> >
> > +config PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT
> > + def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "122")
> > +
>
> This does not seem workable with dummy-tools.
>
> Do we even have dummy pahole?
>
I don't think so but if PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT is broken for
you then the same problem should have happened for the PAHOLE_HAS_SPLIT_BTF
check.
--
Mel Gorman
SUSE Labs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
2021-05-26 8:33 ` (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Michal Suchánek
2021-05-26 9:00 ` Mel Gorman
@ 2021-05-26 17:00 ` Andrii Nakryiko
2021-05-26 17:43 ` Michal Suchánek
1 sibling, 1 reply; 4+ messages in thread
From: Andrii Nakryiko @ 2021-05-26 17:00 UTC (permalink / raw)
To: Michal Suchánek
Cc: Mel Gorman, Linux Kbuild mailing list, Andrew Morton,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, open list,
Arnaldo Carvalho de Melo, Jiri Olsa, Hritik Vijay, bpf, Linux-Net,
Linux-MM, Masahiro Yamada
On Wed, May 26, 2021 at 1:33 AM Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote:
> > Michal Suchanek reported the following problem with linux-next
> >
> > [ 0.000000] Linux version 5.13.0-rc2-next-20210519-1.g3455ff8-vanilla (geeko@buildhost) (gcc (SUSE Linux) 10.3.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-3) #1 SMP Wed May 19 10:05:10 UTC 2021 (3455ff8)
> > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla root=UUID=ec42c33e-a2c2-4c61-afcc-93e9527 8f687 plymouth.enable=0 resume=/dev/disk/by-uuid/f1fe4560-a801-4faf-a638-834c407027c7 mitigations=auto earlyprintk initcall_debug nomodeset earlycon ignore_loglevel console=ttyS0,115200
> > ...
> > [ 26.093364] calling tracing_set_default_clock+0x0/0x62 @ 1
> > [ 26.098937] initcall tracing_set_default_clock+0x0/0x62 returned 0 after 0 usecs
> > [ 26.106330] calling acpi_gpio_handle_deferred_request_irqs+0x0/0x7c @ 1
> > [ 26.113033] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x7c returned 0 after 3 usecs
> > [ 26.121559] calling clk_disable_unused+0x0/0x102 @ 1
> > [ 26.126620] initcall clk_disable_unused+0x0/0x102 returned 0 after 0 usecs
> > [ 26.133491] calling regulator_init_complete+0x0/0x25 @ 1
> > [ 26.138890] initcall regulator_init_complete+0x0/0x25 returned 0 after 0 usecs
> > [ 26.147816] Freeing unused decrypted memory: 2036K
> > [ 26.153682] Freeing unused kernel image (initmem) memory: 2308K
> > [ 26.165776] Write protecting the kernel read-only data: 26624k
> > [ 26.173067] Freeing unused kernel image (text/rodata gap) memory: 2036K
> > [ 26.180416] Freeing unused kernel image (rodata/data gap) memory: 1184K
> > [ 26.187031] Run /init as init process
> > [ 26.190693] with arguments:
> > [ 26.193661] /init
> > [ 26.195933] with environment:
> > [ 26.199079] HOME=/
> > [ 26.201444] TERM=linux
> > [ 26.204152] BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla
> > [ 26.254154] BPF: type_id=35503 offset=178440 size=4
> > [ 26.259125] BPF:
> > [ 26.261054] BPF:Invalid offset
> > [ 26.264119] BPF:
> > [ 26.264119]
> > [ 26.267437] failed to validate module [efivarfs] BTF: -22
> >
> > Andrii Nakryiko bisected the problem to the commit "mm/page_alloc: convert
> > per-cpu list protection to local_lock" currently staged in mmotm. In his
> > own words
> >
> > The immediate problem is two different definitions of numa_node per-cpu
> > variable. They both are at the same offset within .data..percpu ELF
> > section, they both have the same name, but one of them is marked as
> > static and another as global. And one is int variable, while another
> > is struct pagesets. I'll look some more tomorrow, but adding Jiri and
> > Arnaldo for visibility.
> >
> > [110907] DATASEC '.data..percpu' size=178904 vlen=303
> > ...
> > type_id=27753 offset=163976 size=4 (VAR 'numa_node')
> > type_id=27754 offset=163976 size=4 (VAR 'numa_node')
> >
> > [27753] VAR 'numa_node' type_id=27556, linkage=static
> > [27754] VAR 'numa_node' type_id=20, linkage=global
> >
> > [20] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
> >
> > [27556] STRUCT 'pagesets' size=0 vlen=1
> > 'lock' type_id=507 bits_offset=0
> >
> > [506] STRUCT '(anon)' size=0 vlen=0
> > [507] TYPEDEF 'local_lock_t' type_id=506
> >
> > The patch in question introduces a zero-sized per-cpu struct and while
> > this is not wrong, versions of pahole prior to 1.22 (unreleased) get
> > confused during BTF generation with two separate variables occupying the
> > same address.
> >
> > This patch checks for older versions of pahole and forces struct pagesets
> > to be non-zero sized as a workaround when CONFIG_DEBUG_INFO_BTF is set. A
> > warning is omitted so that distributions can update pahole when 1.22
> > is released.
> >
> > Reported-by: Michal Suchanek <msuchanek@suse.de>
> > Reported-by: Hritik Vijay <hritikxx8@gmail.com>
> > Debugged-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> > ---
> > lib/Kconfig.debug | 3 +++
> > mm/page_alloc.c | 11 +++++++++++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 678c13967580..f88a155b80a9 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -313,6 +313,9 @@ config DEBUG_INFO_BTF
> > config PAHOLE_HAS_SPLIT_BTF
> > def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
> >
> > +config PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT
> > + def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "122")
> > +
>
> This does not seem workable with dummy-tools.
>
> Do we even have dummy pahole?
>
I don't know what dummy-tools is, so probably no. But if you don't
have pahole on the build host, you can't have DEBUG_INFO_BTF=y
anyways. As in, your build will fail because it will be impossible to
generate BTF information. So you'll have to disable DEBUG_INFO_BTF if
you can't get pahole onto your build host for some reason.
> Thanks
>
> Michal
>
> > config DEBUG_INFO_BTF_MODULES
> > def_bool y
> > depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index ff8f706839ea..1d56d3de8e08 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -124,6 +124,17 @@ static DEFINE_MUTEX(pcp_batch_high_lock);
> >
> > struct pagesets {
> > local_lock_t lock;
> > +#if defined(CONFIG_DEBUG_INFO_BTF) && \
> > + !defined(CONFIG_DEBUG_LOCK_ALLOC) && \
> > + !defined(CONFIG_PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT)
> > + /*
> > + * pahole 1.21 and earlier gets confused by zero-sized per-CPU
> > + * variables and produces invalid BTF. Ensure that
> > + * sizeof(struct pagesets) != 0 for older versions of pahole.
> > + */
> > + char __pahole_hack;
> > + #warning "pahole too old to support zero-sized struct pagesets"
> > +#endif
> > };
> > static DEFINE_PER_CPU(struct pagesets, pagesets) = {
> > .lock = INIT_LOCAL_LOCK(lock),
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets
2021-05-26 17:00 ` Andrii Nakryiko
@ 2021-05-26 17:43 ` Michal Suchánek
0 siblings, 0 replies; 4+ messages in thread
From: Michal Suchánek @ 2021-05-26 17:43 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Mel Gorman, Linux Kbuild mailing list, Andrew Morton,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, open list,
Arnaldo Carvalho de Melo, Jiri Olsa, Hritik Vijay, bpf, Linux-Net,
Linux-MM, Masahiro Yamada
On Wed, May 26, 2021 at 10:00:34AM -0700, Andrii Nakryiko wrote:
> On Wed, May 26, 2021 at 1:33 AM Michal Suchánek <msuchanek@suse.de> wrote:
> >
> > On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote:
> > > Michal Suchanek reported the following problem with linux-next
> > >
> > > [ 0.000000] Linux version 5.13.0-rc2-next-20210519-1.g3455ff8-vanilla (geeko@buildhost) (gcc (SUSE Linux) 10.3.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-3) #1 SMP Wed May 19 10:05:10 UTC 2021 (3455ff8)
> > > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla root=UUID=ec42c33e-a2c2-4c61-afcc-93e9527 8f687 plymouth.enable=0 resume=/dev/disk/by-uuid/f1fe4560-a801-4faf-a638-834c407027c7 mitigations=auto earlyprintk initcall_debug nomodeset earlycon ignore_loglevel console=ttyS0,115200
> > > ...
> > > [ 26.093364] calling tracing_set_default_clock+0x0/0x62 @ 1
> > > [ 26.098937] initcall tracing_set_default_clock+0x0/0x62 returned 0 after 0 usecs
> > > [ 26.106330] calling acpi_gpio_handle_deferred_request_irqs+0x0/0x7c @ 1
> > > [ 26.113033] initcall acpi_gpio_handle_deferred_request_irqs+0x0/0x7c returned 0 after 3 usecs
> > > [ 26.121559] calling clk_disable_unused+0x0/0x102 @ 1
> > > [ 26.126620] initcall clk_disable_unused+0x0/0x102 returned 0 after 0 usecs
> > > [ 26.133491] calling regulator_init_complete+0x0/0x25 @ 1
> > > [ 26.138890] initcall regulator_init_complete+0x0/0x25 returned 0 after 0 usecs
> > > [ 26.147816] Freeing unused decrypted memory: 2036K
> > > [ 26.153682] Freeing unused kernel image (initmem) memory: 2308K
> > > [ 26.165776] Write protecting the kernel read-only data: 26624k
> > > [ 26.173067] Freeing unused kernel image (text/rodata gap) memory: 2036K
> > > [ 26.180416] Freeing unused kernel image (rodata/data gap) memory: 1184K
> > > [ 26.187031] Run /init as init process
> > > [ 26.190693] with arguments:
> > > [ 26.193661] /init
> > > [ 26.195933] with environment:
> > > [ 26.199079] HOME=/
> > > [ 26.201444] TERM=linux
> > > [ 26.204152] BOOT_IMAGE=/boot/vmlinuz-5.13.0-rc2-next-20210519-1.g3455ff8-vanilla
> > > [ 26.254154] BPF: type_id=35503 offset=178440 size=4
> > > [ 26.259125] BPF:
> > > [ 26.261054] BPF:Invalid offset
> > > [ 26.264119] BPF:
> > > [ 26.264119]
> > > [ 26.267437] failed to validate module [efivarfs] BTF: -22
> > >
> > > Andrii Nakryiko bisected the problem to the commit "mm/page_alloc: convert
> > > per-cpu list protection to local_lock" currently staged in mmotm. In his
> > > own words
> > >
> > > The immediate problem is two different definitions of numa_node per-cpu
> > > variable. They both are at the same offset within .data..percpu ELF
> > > section, they both have the same name, but one of them is marked as
> > > static and another as global. And one is int variable, while another
> > > is struct pagesets. I'll look some more tomorrow, but adding Jiri and
> > > Arnaldo for visibility.
> > >
> > > [110907] DATASEC '.data..percpu' size=178904 vlen=303
> > > ...
> > > type_id=27753 offset=163976 size=4 (VAR 'numa_node')
> > > type_id=27754 offset=163976 size=4 (VAR 'numa_node')
> > >
> > > [27753] VAR 'numa_node' type_id=27556, linkage=static
> > > [27754] VAR 'numa_node' type_id=20, linkage=global
> > >
> > > [20] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
> > >
> > > [27556] STRUCT 'pagesets' size=0 vlen=1
> > > 'lock' type_id=507 bits_offset=0
> > >
> > > [506] STRUCT '(anon)' size=0 vlen=0
> > > [507] TYPEDEF 'local_lock_t' type_id=506
> > >
> > > The patch in question introduces a zero-sized per-cpu struct and while
> > > this is not wrong, versions of pahole prior to 1.22 (unreleased) get
> > > confused during BTF generation with two separate variables occupying the
> > > same address.
> > >
> > > This patch checks for older versions of pahole and forces struct pagesets
> > > to be non-zero sized as a workaround when CONFIG_DEBUG_INFO_BTF is set. A
> > > warning is omitted so that distributions can update pahole when 1.22
> > > is released.
> > >
> > > Reported-by: Michal Suchanek <msuchanek@suse.de>
> > > Reported-by: Hritik Vijay <hritikxx8@gmail.com>
> > > Debugged-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> > > ---
> > > lib/Kconfig.debug | 3 +++
> > > mm/page_alloc.c | 11 +++++++++++
> > > 2 files changed, 14 insertions(+)
> > >
> > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > index 678c13967580..f88a155b80a9 100644
> > > --- a/lib/Kconfig.debug
> > > +++ b/lib/Kconfig.debug
> > > @@ -313,6 +313,9 @@ config DEBUG_INFO_BTF
> > > config PAHOLE_HAS_SPLIT_BTF
> > > def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
> > >
> > > +config PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT
> > > + def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "122")
> > > +
> >
> > This does not seem workable with dummy-tools.
> >
> > Do we even have dummy pahole?
> >
>
> I don't know what dummy-tools is, so probably no. But if you don't
> have pahole on the build host, you can't have DEBUG_INFO_BTF=y
> anyways. As in, your build will fail because it will be impossible to
> generate BTF information. So you'll have to disable DEBUG_INFO_BTF if
> you can't get pahole onto your build host for some reason.
dummy-tools is used to maintain configuration files outside of build
the environment. It is not easy to have all tools with all bells and
whistles for all architectures on one machine. That is you should be
able to enable DEBUG_INFO_BTF without pahole, and then build the config
on a build host that has a compiler and pohole for the target
architecture.
Thanks
Michal
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-05-26 17:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210526080741.GW30378@techsingularity.net>
2021-05-26 8:33 ` (BTF) [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Michal Suchánek
2021-05-26 9:00 ` Mel Gorman
2021-05-26 17:00 ` Andrii Nakryiko
2021-05-26 17:43 ` Michal Suchánek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox