Re: linux-next: build failure after merge of the bpf-next tree

Re: linux-next: build failure after merge of the bpf-next tree

[Magnus Karlsson]

On Thu, Apr 18, 2019 at 3:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc perf)
> failed like this:
>
> In file included from xsk.c:32:
> libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
>  # warning Architecture missing native barrier functions in libbpf_util.h.
>    ^~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
>   b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")
>
> I have applied the following patch for today ... please fix this.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 18 Apr 2019 11:54:56 +1000
> Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  tools/lib/bpf/libbpf_util.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> index 172b707e007b..a54eb2cdbdd6 100644
> --- a/tools/lib/bpf/libbpf_util.h
> +++ b/tools/lib/bpf/libbpf_util.h
> @@ -46,7 +46,7 @@ do {                          \
>  # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
>  # define libbpf_smp_rwmb() libbpf_smp_mb()
>  #else
> -# warning Architecture missing native barrier functions in libbpf_util.h.
> +//# warning Architecture missing native barrier functions in libbpf_util.h.
>  # define libbpf_smp_rmb() __sync_synchronize()
>  # define libbpf_smp_wmb() __sync_synchronize()
>  # define libbpf_smp_mb() __sync_synchronize()
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell

My apologies, I will fix this. I just have two questions first so I do
not mess things up.

* I see my commit in bpf-next but not in bpf. As I submitted it
against bpf, what was the reason it was applied to bpf-next instead?
Unfortunately, I forgot to add "Fixes" tags to the commits, so was
this the reason? I view 4 out of 5 of these patches as bug fixes, the
last one being an optimization.
* Do you want a separate patch for this fix or a V4 of the original
patch set? Against bpf-next or bpf (with Fixes tags)?

Thanks: Magnus

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Thu, Apr 18, 2019 at 07:55:30AM +0200, Magnus Karlsson wrote:
> On Thu, Apr 18, 2019 at 3:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc perf)
> > failed like this:
> >
> > In file included from xsk.c:32:
> > libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
> >  # warning Architecture missing native barrier functions in libbpf_util.h.
> >    ^~~~~~~
> > cc1: all warnings being treated as errors
> >
> > Caused by commit
> >
> >   b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")
> >
> > I have applied the following patch for today ... please fix this.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 18 Apr 2019 11:54:56 +1000
> > Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  tools/lib/bpf/libbpf_util.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> > index 172b707e007b..a54eb2cdbdd6 100644
> > --- a/tools/lib/bpf/libbpf_util.h
> > +++ b/tools/lib/bpf/libbpf_util.h
> > @@ -46,7 +46,7 @@ do {                          \
> >  # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
> >  # define libbpf_smp_rwmb() libbpf_smp_mb()
> >  #else
> > -# warning Architecture missing native barrier functions in libbpf_util.h.
> > +//# warning Architecture missing native barrier functions in libbpf_util.h.
> >  # define libbpf_smp_rmb() __sync_synchronize()
> >  # define libbpf_smp_wmb() __sync_synchronize()
> >  # define libbpf_smp_mb() __sync_synchronize()
> > --
> > 2.20.1
> >
> > --
> > Cheers,
> > Stephen Rothwell
> 
> My apologies, I will fix this. I just have two questions first so I do
> not mess things up.
> 
> * I see my commit in bpf-next but not in bpf. As I submitted it
> against bpf, what was the reason it was applied to bpf-next instead?
> Unfortunately, I forgot to add "Fixes" tags to the commits, so was
> this the reason? I view 4 out of 5 of these patches as bug fixes, the
> last one being an optimization.

new macros that users still have to learn how to use are hardly fixes.

I can toss it out of bpf-next if it's easier.

Re: linux-next: build failure after merge of the bpf-next tree

[Magnus Karlsson]

On Thu, Apr 18, 2019 at 8:18 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Apr 18, 2019 at 07:55:30AM +0200, Magnus Karlsson wrote:
> > On Thu, Apr 18, 2019 at 3:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (powerpc perf)
> > > failed like this:
> > >
> > > In file included from xsk.c:32:
> > > libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
> > >  # warning Architecture missing native barrier functions in libbpf_util.h.
> > >    ^~~~~~~
> > > cc1: all warnings being treated as errors
> > >
> > > Caused by commit
> > >
> > >   b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")
> > >
> > > I have applied the following patch for today ... please fix this.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 18 Apr 2019 11:54:56 +1000
> > > Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  tools/lib/bpf/libbpf_util.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> > > index 172b707e007b..a54eb2cdbdd6 100644
> > > --- a/tools/lib/bpf/libbpf_util.h
> > > +++ b/tools/lib/bpf/libbpf_util.h
> > > @@ -46,7 +46,7 @@ do {                          \
> > >  # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
> > >  # define libbpf_smp_rwmb() libbpf_smp_mb()
> > >  #else
> > > -# warning Architecture missing native barrier functions in libbpf_util.h.
> > > +//# warning Architecture missing native barrier functions in libbpf_util.h.
> > >  # define libbpf_smp_rmb() __sync_synchronize()
> > >  # define libbpf_smp_wmb() __sync_synchronize()
> > >  # define libbpf_smp_mb() __sync_synchronize()
> > > --
> > > 2.20.1
> > >
> > > --
> > > Cheers,
> > > Stephen Rothwell
> >
> > My apologies, I will fix this. I just have two questions first so I do
> > not mess things up.
> >
> > * I see my commit in bpf-next but not in bpf. As I submitted it
> > against bpf, what was the reason it was applied to bpf-next instead?
> > Unfortunately, I forgot to add "Fixes" tags to the commits, so was
> > this the reason? I view 4 out of 5 of these patches as bug fixes, the
> > last one being an optimization.
>
> new macros that users still have to learn how to use are hardly fixes.

That is fair.

> I can toss it out of bpf-next if it's easier.

How about you toss it out of bpf-next, then I resubmit the first two
patches (the barrier fixes) to bpf and the last three (new macros,
etc.) to bpf-next? Would that make it easier for you?

Thanks: Magnus


/Magnus

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Thu, Apr 18, 2019 at 08:25:22AM +0200, Magnus Karlsson wrote:
> On Thu, Apr 18, 2019 at 8:18 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Apr 18, 2019 at 07:55:30AM +0200, Magnus Karlsson wrote:
> > > On Thu, Apr 18, 2019 at 3:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > After merging the bpf-next tree, today's linux-next build (powerpc perf)
> > > > failed like this:
> > > >
> > > > In file included from xsk.c:32:
> > > > libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
> > > >  # warning Architecture missing native barrier functions in libbpf_util.h.
> > > >    ^~~~~~~
> > > > cc1: all warnings being treated as errors
> > > >
> > > > Caused by commit
> > > >
> > > >   b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")
> > > >
> > > > I have applied the following patch for today ... please fix this.
> > > >
> > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > Date: Thu, 18 Apr 2019 11:54:56 +1000
> > > > Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h
> > > >
> > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > ---
> > > >  tools/lib/bpf/libbpf_util.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> > > > index 172b707e007b..a54eb2cdbdd6 100644
> > > > --- a/tools/lib/bpf/libbpf_util.h
> > > > +++ b/tools/lib/bpf/libbpf_util.h
> > > > @@ -46,7 +46,7 @@ do {                          \
> > > >  # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
> > > >  # define libbpf_smp_rwmb() libbpf_smp_mb()
> > > >  #else
> > > > -# warning Architecture missing native barrier functions in libbpf_util.h.
> > > > +//# warning Architecture missing native barrier functions in libbpf_util.h.
> > > >  # define libbpf_smp_rmb() __sync_synchronize()
> > > >  # define libbpf_smp_wmb() __sync_synchronize()
> > > >  # define libbpf_smp_mb() __sync_synchronize()
> > > > --
> > > > 2.20.1
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> > >
> > > My apologies, I will fix this. I just have two questions first so I do
> > > not mess things up.
> > >
> > > * I see my commit in bpf-next but not in bpf. As I submitted it
> > > against bpf, what was the reason it was applied to bpf-next instead?
> > > Unfortunately, I forgot to add "Fixes" tags to the commits, so was
> > > this the reason? I view 4 out of 5 of these patches as bug fixes, the
> > > last one being an optimization.
> >
> > new macros that users still have to learn how to use are hardly fixes.
> 
> That is fair.
> 
> > I can toss it out of bpf-next if it's easier.
> 
> How about you toss it out of bpf-next, then I resubmit the first two
> patches (the barrier fixes) to bpf and the last three (new macros,
> etc.) to bpf-next? Would that make it easier for you?

the easiest is to do a trivial patch for bpf-next,
but if you insist on first two as fixes that is ok as well.

Re: linux-next: build failure after merge of the bpf-next tree

[Magnus Karlsson]

On Thu, Apr 18, 2019 at 8:51 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Apr 18, 2019 at 08:25:22AM +0200, Magnus Karlsson wrote:
> > On Thu, Apr 18, 2019 at 8:18 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Thu, Apr 18, 2019 at 07:55:30AM +0200, Magnus Karlsson wrote:
> > > > On Thu, Apr 18, 2019 at 3:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > After merging the bpf-next tree, today's linux-next build (powerpc perf)
> > > > > failed like this:
> > > > >
> > > > > In file included from xsk.c:32:
> > > > > libbpf_util.h:49:3: error: #warning Architecture missing native barrier functions in libbpf_util.h. [-Werror=cpp]
> > > > >  # warning Architecture missing native barrier functions in libbpf_util.h.
> > > > >    ^~~~~~~
> > > > > cc1: all warnings being treated as errors
> > > > >
> > > > > Caused by commit
> > > > >
> > > > >   b7e3a28019c9 ("libbpf: remove dependency on barrier.h in xsk.h")
> > > > >
> > > > > I have applied the following patch for today ... please fix this.
> > > > >
> > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > Date: Thu, 18 Apr 2019 11:54:56 +1000
> > > > > Subject: [PATCH] suppress warning in tools/lib/bpf/libbpf_util.h
> > > > >
> > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > ---
> > > > >  tools/lib/bpf/libbpf_util.h | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> > > > > index 172b707e007b..a54eb2cdbdd6 100644
> > > > > --- a/tools/lib/bpf/libbpf_util.h
> > > > > +++ b/tools/lib/bpf/libbpf_util.h
> > > > > @@ -46,7 +46,7 @@ do {                          \
> > > > >  # define libbpf_smp_mb() asm volatile("dmb ish" : : : "memory")
> > > > >  # define libbpf_smp_rwmb() libbpf_smp_mb()
> > > > >  #else
> > > > > -# warning Architecture missing native barrier functions in libbpf_util.h.
> > > > > +//# warning Architecture missing native barrier functions in libbpf_util.h.
> > > > >  # define libbpf_smp_rmb() __sync_synchronize()
> > > > >  # define libbpf_smp_wmb() __sync_synchronize()
> > > > >  # define libbpf_smp_mb() __sync_synchronize()
> > > > > --
> > > > > 2.20.1
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Stephen Rothwell
> > > >
> > > > My apologies, I will fix this. I just have two questions first so I do
> > > > not mess things up.
> > > >
> > > > * I see my commit in bpf-next but not in bpf. As I submitted it
> > > > against bpf, what was the reason it was applied to bpf-next instead?
> > > > Unfortunately, I forgot to add "Fixes" tags to the commits, so was
> > > > this the reason? I view 4 out of 5 of these patches as bug fixes, the
> > > > last one being an optimization.
> > >
> > > new macros that users still have to learn how to use are hardly fixes.
> >
> > That is fair.
> >
> > > I can toss it out of bpf-next if it's easier.
> >
> > How about you toss it out of bpf-next, then I resubmit the first two
> > patches (the barrier fixes) to bpf and the last three (new macros,
> > etc.) to bpf-next? Would that make it easier for you?
>
> the easiest is to do a trivial patch for bpf-next,
> but if you insist on first two as fixes that is ok as well.

Will submit a trivial patch. Thanks for your quick answers and help.

/Magnus

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

kernel/bpf/core.c:830:23: error: variably modified 'bitmap' at file scope
  830 |         unsigned long bitmap[BITS_TO_LONGS(BPF_PROG_CHUNK_COUNT)];
      |                       ^~~~~~

Caused by commit

  57631054fae6 ("bpf: Introduce bpf_prog_pack allocator")

I have used the bpf-next tree from next-20220208 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build
(x86_64 allmodconfig) failed like this:

In file included from include/linux/compiler_types.h:73,
                 from <command-line>:
drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
  222 | # define fallthrough                    __attribute__((__fallthrough__))
      |                                         ^~~~~~~~~~~~~
drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
  192 |                 fallthrough; /* handle aborts by dropping packet */
      |                 ^~~~~~~~~~~
cc1: all warnings being treated as errors
In file included from include/linux/compiler_types.h:73,
                 from <command-line>:
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
  222 | # define fallthrough                    __attribute__((__fallthrough__))
      |                                         ^~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
  147 |                 fallthrough; /* handle aborts by dropping packet */
      |                 ^~~~~~~~~~~
cc1: all warnings being treated as errors

Caused by commits

  b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
  c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")

I have used the bpf-next tree from next-20220414 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

Hi all,

On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
> 
> In file included from include/linux/compiler_types.h:73,
>                  from <command-line>:
> drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>   222 | # define fallthrough                    __attribute__((__fallthrough__))
>       |                                         ^~~~~~~~~~~~~
> drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
>   192 |                 fallthrough; /* handle aborts by dropping packet */
>       |                 ^~~~~~~~~~~
> cc1: all warnings being treated as errors
> In file included from include/linux/compiler_types.h:73,
>                  from <command-line>:
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>   222 | # define fallthrough                    __attribute__((__fallthrough__))
>       |                                         ^~~~~~~~~~~~~
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
>   147 |                 fallthrough; /* handle aborts by dropping packet */
>       |                 ^~~~~~~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commits
> 
>   b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>   c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> 
> I have used the bpf-next tree from next-20220414 for today.

I am still getting these failures ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Daniel Borkmann]

On 4/21/22 2:32 AM, Stephen Rothwell wrote:
> Hi all,

Maciej, I presume you are already working on a follow-up for the below?

> On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the bpf-next tree, today's linux-next build
>> (x86_64 allmodconfig) failed like this:
>>
>> In file included from include/linux/compiler_types.h:73,
>>                   from <command-line>:
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
>> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>>    222 | # define fallthrough                    __attribute__((__fallthrough__))
>>        |                                         ^~~~~~~~~~~~~
>> drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
>>    192 |                 fallthrough; /* handle aborts by dropping packet */
>>        |                 ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>> In file included from include/linux/compiler_types.h:73,
>>                   from <command-line>:
>> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
>> include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
>>    222 | # define fallthrough                    __attribute__((__fallthrough__))
>>        |                                         ^~~~~~~~~~~~~
>> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
>>    147 |                 fallthrough; /* handle aborts by dropping packet */
>>        |                 ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>>
>> Caused by commits
>>
>>    b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>>    c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
>>
>> I have used the bpf-next tree from next-20220414 for today.
> 
> I am still getting these failures ...
> 

Re: linux-next: build failure after merge of the bpf-next tree

[Maciej Fijalkowski]

On Thu, Apr 21, 2022 at 11:45:46AM +0200, Daniel Borkmann wrote:
> On 4/21/22 2:32 AM, Stephen Rothwell wrote:
> > Hi all,
> 
> Maciej, I presume you are already working on a follow-up for the below?

Yikes! I missed that, let's blame easter break for that.
I'm on it.

> 
> > On Tue, 19 Apr 2022 11:56:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > After merging the bpf-next tree, today's linux-next build
> > > (x86_64 allmodconfig) failed like this:
> > > 
> > > In file included from include/linux/compiler_types.h:73,
> > >                   from <command-line>:
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c: In function 'i40e_run_xdp_zc':
> > > include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
> > >    222 | # define fallthrough                    __attribute__((__fallthrough__))
> > >        |                                         ^~~~~~~~~~~~~
> > > drivers/net/ethernet/intel/i40e/i40e_xsk.c:192:17: note: in expansion of macro 'fallthrough'
> > >    192 |                 fallthrough; /* handle aborts by dropping packet */
> > >        |                 ^~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > > In file included from include/linux/compiler_types.h:73,
> > >                   from <command-line>:
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c: In function 'ixgbe_run_xdp_zc':
> > > include/linux/compiler_attributes.h:222:41: error: attribute 'fallthrough' not preceding a case label or default label [-Werror]
> > >    222 | # define fallthrough                    __attribute__((__fallthrough__))
> > >        |                                         ^~~~~~~~~~~~~
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c:147:17: note: in expansion of macro 'fallthrough'
> > >    147 |                 fallthrough; /* handle aborts by dropping packet */
> > >        |                 ^~~~~~~~~~~
> > > cc1: all warnings being treated as errors
> > > 
> > > Caused by commits
> > > 
> > >    b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> > >    c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full")
> > > 
> > > I have used the bpf-next tree from next-20220414 for today.
> > 
> > I am still getting these failures ...
> > 
> 

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ld: warning: discarding dynamic section .glink
ld: warning: discarding dynamic section .plt
ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
ld: stubs don't match calculated size
ld: can not build stubs: bad value
ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'

Caused by commit

  3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Tue, Jul 19, 2022 at 7:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ld: warning: discarding dynamic section .glink
> ld: warning: discarding dynamic section .plt
> ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
> ld: stubs don't match calculated size
> ld: can not build stubs: bad value
> ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
> cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
> cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
>
> Caused by commit
>
>   3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")
>
> I have reverted that commit for today.

Argh.

Stan,

please take a look.

Re: linux-next: build failure after merge of the bpf-next tree

[Stanislav Fomichev]

On Tue, Jul 19, 2022 at 8:42 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jul 19, 2022 at 7:00 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ld: warning: discarding dynamic section .glink
> > ld: warning: discarding dynamic section .plt
> > ld: linkage table error against `bpf_trampoline_unlink_cgroup_shim'
> > ld: stubs don't match calculated size
> > ld: can not build stubs: bad value
> > ld: kernel/bpf/cgroup.o: in function `.bpf_cgroup_link_release.part.0':
> > cgroup.c:(.text+0x2fc4): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> > ld: kernel/bpf/cgroup.o: in function `.cgroup_bpf_release':
> > cgroup.c:(.text+0x33b0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> > ld: cgroup.c:(.text+0x33c0): undefined reference to `.bpf_trampoline_unlink_cgroup_shim'
> >
> > Caused by commit
> >
> >   3908fcddc65d ("bpf: fix lsm_cgroup build errors on esoteric configs")
> >
> > I have reverted that commit for today.
>
> Argh.
>
> Stan,
>
> please take a look.

Sorry about that, I forgot to update the ifdef guards in the header
:-( Will send a fix shortly..

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

net/bpf/test_run.c: In function 'frame_was_changed':
net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
  224 |         return head->frm.data != head->orig_ctx.data ||
      |                      ^~~
      |                      frame
net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
  225 |                head->frm.flags != head->orig_ctx.flags;
      |                      ^~~
      |                      frame

Caused by commit

  e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")

I have used the bpf-next tree from next-20230317 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alexander Lobakin]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Mar 2023 10:26:19 +1100

> Hi all,

Hi,

> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> net/bpf/test_run.c: In function 'frame_was_changed':
> net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
>   224 |         return head->frm.data != head->orig_ctx.data ||
>       |                      ^~~
>       |                      frame
> net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
>   225 |                head->frm.flags != head->orig_ctx.flags;
>       |                      ^~~
>       |                      frame

The correct solution is to change `frm.` with `frame->`, but I hope the
BPF maintainers will merge bpf into bpf-next to pick up fixes and
changes like this :)

> 
> Caused by commit
> 
>   e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")
> 
> I have used the bpf-next tree from next-20230317 for today.
> 

Thanks,
Olek

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi all,

On Mon, 20 Mar 2023 13:07:23 +0100 Alexander Lobakin <aleksander.lobakin@intel.com> wrote:
>
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > net/bpf/test_run.c: In function 'frame_was_changed':
> > net/bpf/test_run.c:224:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
> >   224 |         return head->frm.data != head->orig_ctx.data ||
> >       |                      ^~~
> >       |                      frame
> > net/bpf/test_run.c:225:22: error: 'const struct xdp_page_head' has no member named 'frm'; did you mean 'frame'?
> >   225 |                head->frm.flags != head->orig_ctx.flags;
> >       |                      ^~~
> >       |                      frame  
> 
> The correct solution is to change `frm.` with `frame->`, but I hope the
> BPF maintainers will merge bpf into bpf-next to pick up fixes and
> changes like this :)

Well, that hasn't happened yet, so I will apply the following patch
until it does.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 22 Mar 2023 09:20:26 +1100
Subject: [PATCH] bpf, test_run: fix up for "bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES"

ineracting with commit

  e5995bc7e2ba ("bpf, test_run: fix crashes due to XDP frame overwriting/corruption")

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/bpf/test_run.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index af5804d6bff2..c2bab8e20406 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -221,8 +221,8 @@ static bool frame_was_changed(const struct xdp_page_head *head)
 	 * i.e. has the highest chances to be overwritten. If those two are
 	 * untouched, it's most likely safe to skip the context reset.
 	 */
-	return head->frm.data != head->orig_ctx.data ||
-	       head->frm.flags != head->orig_ctx.flags;
+	return head->frame->data != head->orig_ctx.data ||
+	       head->frame->flags != head->orig_ctx.flags;
 }
 
 static bool ctx_was_changed(struct xdp_page_head *head)
-- 
2.39.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
  280 |         .reg = hid_bpf_reg,
      |                ^~~~~~~~~~~
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
  281 |         .unreg = hid_bpf_unreg,
      |                  ^~~~~~~~~~~~~
/tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')

Caused by commit

  73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")

interacting with commit

  ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")

from the HID tree.

I've fixed it up as below:

From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie@kernel.org>
Date: Mon, 17 Jun 2024 19:02:27 +0100
Subject: [PATCH] HID: bpf: Fix up build

Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
index 5f200557ff12b..744318e7d936b 100644
--- a/drivers/hid/bpf/hid_bpf_struct_ops.c
+++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
@@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
 	return 0;
 }
 
-static int hid_bpf_reg(void *kdata)
+static int hid_bpf_reg(void *kdata, struct bpf_link *link)
 {
 	struct hid_bpf_ops *ops = kdata;
 	struct hid_device *hdev;
@@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
 	return err;
 }
 
-static void hid_bpf_unreg(void *kdata)
+static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
 {
 	struct hid_bpf_ops *ops = kdata;
 	struct hid_device *hdev;
-- 
2.39.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[kernel test robot]

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on hid/for-next]
[cannot apply to linus/master v6.10-rc4 next-20240621]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-bpf-next-tree/20240618-022240
base:   https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link:    https://lore.kernel.org/r/ZnB9X1Jj6c04ufC0%40sirena.org.uk
patch subject: linux-next: build failure after merge of the bpf-next tree
config: x86_64-randconfig-r122-20240622 (https://download.01.org/0day-ci/archive/20240622/202406221655.xSqDIUk6-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240622/202406221655.xSqDIUk6-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406221655.xSqDIUk6-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/hid/bpf/hid_bpf_struct_ops.c:280:9: error: incompatible function pointer types initializing 'int (*)(void *)' with an expression of type 'int (void *, struct bpf_link *)' [-Wincompatible-function-pointer-types]
     280 |         .reg = hid_bpf_reg,
         |                ^~~~~~~~~~~
>> drivers/hid/bpf/hid_bpf_struct_ops.c:281:11: error: incompatible function pointer types initializing 'void (*)(void *)' with an expression of type 'void (void *, struct bpf_link *)' [-Wincompatible-function-pointer-types]
     281 |         .unreg = hid_bpf_unreg,
         |                  ^~~~~~~~~~~~~
   2 errors generated.


vim +280 drivers/hid/bpf/hid_bpf_struct_ops.c

ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  274  
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  275  static struct bpf_struct_ops bpf_hid_bpf_ops = {
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  276  	.verifier_ops = &hid_bpf_verifier_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  277  	.init = hid_bpf_ops_init,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  278  	.check_member = hid_bpf_ops_check_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  279  	.init_member = hid_bpf_ops_init_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @280  	.reg = hid_bpf_reg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @281  	.unreg = hid_bpf_unreg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  282  	.name = "hid_bpf_ops",
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  283  	.cfi_stubs = &__bpf_hid_bpf_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  284  	.owner = THIS_MODULE,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  285  };
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  286  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: linux-next: build failure after merge of the bpf-next tree

[kernel test robot]

Hi Mark,

kernel test robot noticed the following build errors:

[auto build test ERROR on hid/for-next]
[cannot apply to linus/master v6.10-rc4 next-20240621]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Mark-Brown/linux-next-build-failure-after-merge-of-the-bpf-next-tree/20240618-022240
base:   https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link:    https://lore.kernel.org/r/ZnB9X1Jj6c04ufC0%40sirena.org.uk
patch subject: linux-next: build failure after merge of the bpf-next tree
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20240622/202406221626.JK0Nnkxy-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240622/202406221626.JK0Nnkxy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406221626.JK0Nnkxy-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *)' from incompatible pointer type 'int (*)(void *, struct bpf_link *)' [-Werror=incompatible-pointer-types]
     280 |         .reg = hid_bpf_reg,
         |                ^~~~~~~~~~~
   drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
>> drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *)' from incompatible pointer type 'void (*)(void *, struct bpf_link *)' [-Werror=incompatible-pointer-types]
     281 |         .unreg = hid_bpf_unreg,
         |                  ^~~~~~~~~~~~~
   drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
   cc1: some warnings being treated as errors


vim +280 drivers/hid/bpf/hid_bpf_struct_ops.c

ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  274  
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  275  static struct bpf_struct_ops bpf_hid_bpf_ops = {
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  276  	.verifier_ops = &hid_bpf_verifier_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  277  	.init = hid_bpf_ops_init,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  278  	.check_member = hid_bpf_ops_check_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  279  	.init_member = hid_bpf_ops_init_member,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @280  	.reg = hid_bpf_reg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08 @281  	.unreg = hid_bpf_unreg,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  282  	.name = "hid_bpf_ops",
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  283  	.cfi_stubs = &__bpf_hid_bpf_ops,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  284  	.owner = THIS_MODULE,
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  285  };
ebc0d8093e8c97 Benjamin Tissoires 2024-06-08  286  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: linux-next: build failure after merge of the bpf-next tree

[Thinker Li]

Hi Mark,

I'm sorry for not getting back to you sooner. I have been traveling
since my last message.
I guess this patch is for the HID tree. The changes in this patch are great.

However, I suggest you implement ".update" if you think it is
reasonable for HID,
although it is not a MUST-BE. ".update" provides a good feature that
user space programs
can update an implementation on the flight.

On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
>   280 |         .reg = hid_bpf_reg,
>       |                ^~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
>   281 |         .unreg = hid_bpf_unreg,
>       |                  ^~~~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
>
> Caused by commit
>
>   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> interacting with commit
>
>   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
>
> from the HID tree.
>
> I've fixed it up as below:
>
> From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@kernel.org>
> Date: Mon, 17 Jun 2024 19:02:27 +0100
> Subject: [PATCH] HID: bpf: Fix up build
>
> Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 5f200557ff12b..744318e7d936b 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
>         return 0;
>  }
>
> -static int hid_bpf_reg(void *kdata)
> +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
>  {
>         struct hid_bpf_ops *ops = kdata;
>         struct hid_device *hdev;
> @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
>         return err;
>  }
>
> -static void hid_bpf_unreg(void *kdata)
> +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
>  {
>         struct hid_bpf_ops *ops = kdata;
>         struct hid_device *hdev;
> --
> 2.39.2
>

Re: linux-next: build failure after merge of the bpf-next tree

[Benjamin Tissoires]

On Jun 24 2024, Thinker Li wrote:
> Hi Mark,
> 
> I'm sorry for not getting back to you sooner. I have been traveling
> since my last message.
> I guess this patch is for the HID tree. The changes in this patch are great.

Ok, thanks for the review. However, the need appears because there is a
conflicting update in the bpf tree.

May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
tag I could merge to so I can take this patch from Mark?

> 
> However, I suggest you implement ".update" if you think it is
> reasonable for HID,
> although it is not a MUST-BE. ".update" provides a good feature that
> user space programs
> can update an implementation on the flight.

FWIW, Mark handles linux-next, so not sure he has deep knowledge of
HID-BPF, and not sure he wants too :)

Regarding .update, I'm not sure it's worth the effort for hid-bpf. Right
now HID-BPF programs are just a one-shot: you load them, pin them and
forget. This might be different when systemd starts implementing a HID
firewall, but we can cross that bridge when we see fit.

Cheers,
Benjamin

> 
> On Mon, Jun 17, 2024 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> >   280 |         .reg = hid_bpf_reg,
> >       |                ^~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> >   281 |         .unreg = hid_bpf_unreg,
> >       |                  ^~~~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> >
> > Caused by commit
> >
> >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > interacting with commit
> >
> >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> >
> > from the HID tree.
> >
> > I've fixed it up as below:
> >
> > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > From: Mark Brown <broonie@kernel.org>
> > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > Subject: [PATCH] HID: bpf: Fix up build
> >
> > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > index 5f200557ff12b..744318e7d936b 100644
> > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> >         return 0;
> >  }
> >
> > -static int hid_bpf_reg(void *kdata)
> > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> >  {
> >         struct hid_bpf_ops *ops = kdata;
> >         struct hid_device *hdev;
> > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> >         return err;
> >  }
> >
> > -static void hid_bpf_unreg(void *kdata)
> > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> >  {
> >         struct hid_bpf_ops *ops = kdata;
> >         struct hid_device *hdev;
> > --
> > 2.39.2
> >

Re: linux-next: build failure after merge of the bpf-next tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Tue, Jun 25, 2024 at 05:54:47PM +0200, Benjamin Tissoires wrote:
> On Jun 24 2024, Thinker Li wrote:

> > However, I suggest you implement ".update" if you think it is
> > reasonable for HID,
> > although it is not a MUST-BE. ".update" provides a good feature that
> > user space programs
> > can update an implementation on the flight.

> FWIW, Mark handles linux-next, so not sure he has deep knowledge of
> HID-BPF, and not sure he wants too :)

Only holiday cover but yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Tue, Jun 25, 2024 at 8:54 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> On Jun 24 2024, Thinker Li wrote:
> > Hi Mark,
> >
> > I'm sorry for not getting back to you sooner. I have been traveling
> > since my last message.
> > I guess this patch is for the HID tree. The changes in this patch are great.
>
> Ok, thanks for the review. However, the need appears because there is a
> conflicting update in the bpf tree.
>
> May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
> tag I could merge to so I can take this patch from Mark?

I'm not sure how that would look like.
imo conflict is minor enough.
When net-next/bpf-next lands in the upcoming merge window
just provide Mark's patch as a conflict resolution suggestion
in the cover letter of hid PR ?

Re: linux-next: build failure after merge of the bpf-next tree

[Benjamin Tissoires]

On Jun 25 2024, Alexei Starovoitov wrote:
> On Tue, Jun 25, 2024 at 8:54 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
> >
> > On Jun 24 2024, Thinker Li wrote:
> > > Hi Mark,
> > >
> > > I'm sorry for not getting back to you sooner. I have been traveling
> > > since my last message.
> > > I guess this patch is for the HID tree. The changes in this patch are great.
> >
> > Ok, thanks for the review. However, the need appears because there is a
> > conflicting update in the bpf tree.
> >
> > May I ask the bpf maintainers (Daniel/Alexei/Andrii) for an immutable
> > tag I could merge to so I can take this patch from Mark?
> 
> I'm not sure how that would look like.
> imo conflict is minor enough.
> When net-next/bpf-next lands in the upcoming merge window
> just provide Mark's patch as a conflict resolution suggestion
> in the cover letter of hid PR ?

I guess I can also wait for the bpf PR to come in, merge with it and add
Mark's patch at that time. It's not so much of a conflict but 2
independant changes in 2 different trees.

Anyway, we'll figure it out when we need :)

Cheers,
Benjamin

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]

Hi all,

On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
>   280 |         .reg = hid_bpf_reg,
>       |                ^~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
>   281 |         .unreg = hid_bpf_unreg,
>       |                  ^~~~~~~~~~~~~
> /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> 
> Caused by commit
> 
>   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> 
> interacting with commit
> 
>   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> 
> from the HID tree.
> 
> I've fixed it up as below:
> 
> From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@kernel.org>
> Date: Mon, 17 Jun 2024 19:02:27 +0100
> Subject: [PATCH] HID: bpf: Fix up build
> 
> Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 5f200557ff12b..744318e7d936b 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
>  	return 0;
>  }
>  
> -static int hid_bpf_reg(void *kdata)
> +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
>  {
>  	struct hid_bpf_ops *ops = kdata;
>  	struct hid_device *hdev;
> @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
>  	return err;
>  }
>  
> -static void hid_bpf_unreg(void *kdata)
> +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
>  {
>  	struct hid_bpf_ops *ops = kdata;
>  	struct hid_device *hdev;
> -- 
> 2.39.2
> 

This fixup is now required when the hid and next-next trees are merged.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2997 bytes --]

Hi all,

On Wed, 10 Jul 2024 09:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> >   280 |         .reg = hid_bpf_reg,
> >       |                ^~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> >   281 |         .unreg = hid_bpf_unreg,
> >       |                  ^~~~~~~~~~~~~
> > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> > 
> > Caused by commit
> > 
> >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > 
> > interacting with commit
> > 
> >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> > 
> > from the HID tree.
> > 
> > I've fixed it up as below:
> > 
> > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > From: Mark Brown <broonie@kernel.org>
> > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > Subject: [PATCH] HID: bpf: Fix up build
> > 
> > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > 
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > index 5f200557ff12b..744318e7d936b 100644
> > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> >  	return 0;
> >  }
> >  
> > -static int hid_bpf_reg(void *kdata)
> > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> >  {
> >  	struct hid_bpf_ops *ops = kdata;
> >  	struct hid_device *hdev;
> > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> >  	return err;
> >  }
> >  
> > -static void hid_bpf_unreg(void *kdata)
> > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> >  {
> >  	struct hid_bpf_ops *ops = kdata;
> >  	struct hid_device *hdev;
> > -- 
> > 2.39.2
> >   
> 
> This fixup is now required when the hid and next-next trees are merged.

And now this is needed when the hid tree is merged with Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Benjamin Tissoires]

Hi Stephen,

On Jul 18 2024, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 10 Jul 2024 09:13:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 17 Jun 2024 19:15:59 +0100 Mark Brown <broonie@kernel.org> wrote:
> > >
> > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: error: initialization of 'int (*)(void *, struct bpf_link *)' from incompatible pointer type 'int (*)(void *)' [-Werror=incompatible-pointer-types]
> > >   280 |         .reg = hid_bpf_reg,
> > >       |                ^~~~~~~~~~~
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:280:16: note: (near initialization for 'bpf_hid_bpf_ops.reg')
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: error: initialization of 'void (*)(void *, struct bpf_link *)' from incompatible pointer type 'void (*)(void *)' [-Werror=incompatible-pointer-types]
> > >   281 |         .unreg = hid_bpf_unreg,
> > >       |                  ^~~~~~~~~~~~~
> > > /tmp/next/build/drivers/hid/bpf/hid_bpf_struct_ops.c:281:18: note: (near initialization for 'bpf_hid_bpf_ops.unreg')
> > > 
> > > Caused by commit
> > > 
> > >   73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > > 
> > > interacting with commit
> > > 
> > >   ebc0d8093e8c97 ("HID: bpf: implement HID-BPF through bpf_struct_ops")
> > > 
> > > from the HID tree.
> > > 
> > > I've fixed it up as below:
> > > 
> > > From e8aeaba00440845f9bd8d6183ca5d7383a678cd3 Mon Sep 17 00:00:00 2001
> > > From: Mark Brown <broonie@kernel.org>
> > > Date: Mon, 17 Jun 2024 19:02:27 +0100
> > > Subject: [PATCH] HID: bpf: Fix up build
> > > 
> > > Fix up build error due to 73287fe228721b ("bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops.")
> > > 
> > > Signed-off-by: Mark Brown <broonie@kernel.org>
> > > ---
> > >  drivers/hid/bpf/hid_bpf_struct_ops.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > index 5f200557ff12b..744318e7d936b 100644
> > > --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> > > @@ -175,7 +175,7 @@ static int hid_bpf_ops_init_member(const struct btf_type *t,
> > >  	return 0;
> > >  }
> > >  
> > > -static int hid_bpf_reg(void *kdata)
> > > +static int hid_bpf_reg(void *kdata, struct bpf_link *link)
> > >  {
> > >  	struct hid_bpf_ops *ops = kdata;
> > >  	struct hid_device *hdev;
> > > @@ -229,7 +229,7 @@ static int hid_bpf_reg(void *kdata)
> > >  	return err;
> > >  }
> > >  
> > > -static void hid_bpf_unreg(void *kdata)
> > > +static void hid_bpf_unreg(void *kdata, struct bpf_link *link)
> > >  {
> > >  	struct hid_bpf_ops *ops = kdata;
> > >  	struct hid_device *hdev;
> > > -- 
> > > 2.39.2
> > >   
> > 
> > This fixup is now required when the hid and next-next trees are merged.
> 
> And now this is needed when the hid tree is merged with Linus' tree.
> 

Thanks a lot for all of your reminders.

The HID PR has been accepted and merged thanks to both of your merge
conflicts detection, Mark and you. So this conflict should no longer be a
problem.

Cheers,
Benjamin

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/namespace.c: In function 'grab_requested_mnt_ns':
fs/namespace.c:5295:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5295 |                 if (!f.file)
      |                       ^
fs/namespace.c:5298:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5298 |                 if (!proc_ns_file(f.file))
      |                                    ^
In file included from fs/namespace.c:25:
fs/namespace.c:5301:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5301 |                 ns = get_proc_ns(file_inode(f.file));
      |                                              ^
include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
   75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
      |                                                  ^~~~~

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  7b9d14af8777 ("fs: allow mount namespace fd")

from the vfs-brauner tree.

I applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:07:38 +1000
Subject: [PATCH] fixup for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from hte vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 159be8ed9d24..7aed325c48ad 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5292,13 +5292,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (!fd_file(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5791 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/xattr.c: In function 'path_getxattrat':
fs/xattr.c:832:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  832 |                 if (!f.file)
      |                       ^
fs/xattr.c:834:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  834 |                 audit_file(f.file);
      |                             ^
fs/xattr.c:835:49: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                 ^
fs/xattr.c:835:70: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                                      ^
fs/xattr.c: In function 'path_listxattrat':
fs/xattr.c:952:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  952 |                 if (!f.file)
      |                       ^
fs/xattr.c:954:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  954 |                 audit_file(f.file);
      |                             ^
fs/xattr.c:955:47: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  955 |                 return listxattr(file_dentry(f.file), list, size);
      |                                               ^
fs/xattr.c: In function 'do_fremovexattr':
fs/xattr.c:1021:15: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1021 |         if (!f.file)
      |               ^
fs/xattr.c:1023:21: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1023 |         audit_file(f.file);
      |                     ^
fs/xattr.c:1031:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1031 |         error = mnt_want_write_file(f.file);
      |                                      ^
fs/xattr.c:1033:53: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1033 |                 error = removexattr(file_mnt_idmap(f.file),
      |                                                     ^
fs/xattr.c:1034:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1034 |                                     f.file->f_path.dentry, kname);
      |                                      ^
fs/xattr.c:1035:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1035 |                 mnt_drop_write_file(f.file);
      |                                      ^

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

I applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:20:43 +1000
Subject: [PATCH] fixup2 for "introduce fd_file(), convert all accessors to
 it."

interacting with

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..c0ecd0809172 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (!fd_file(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (!fd_file(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (!fd_file(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Al Viro]

On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (!fd_file(f))

		if (fd_empty(f))

actually, and similar for the rest of it.  Anyway, that'll need to be
sorted out in vfs/vfs.git; sorry about the delay.

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]

Hi Al,

On Wed, 14 Aug 2024 02:41:57 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
> >  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
> >  		CLASS(fd, f)(dfd);
> > -		if (!f.file)
> > +		if (!fd_file(f))  
> 
> 		if (fd_empty(f))
> 
> actually, and similar for the rest of it.  Anyway, that'll need to be
> sorted out in vfs/vfs.git; sorry about the delay.

So from tomorrow, the two merge resolution patches will be these:

rom: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:07:38 +1000
Subject: [PATCH] fixup for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 159be8ed9d24..7aed325c48ad 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5292,13 +5292,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (fd_empty(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.43.0

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2024 11:20:43 +1000
Subject: [PATCH] fixup2 for "introduce fd_file(), convert all accessors to it."

interacting with

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..c0ecd0809172 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (fd_empty(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Christian Brauner]

On Wed, Aug 14, 2024 at 02:41:57AM GMT, Al Viro wrote:
> On Wed, Aug 14, 2024 at 11:25:04AM +1000, Stephen Rothwell wrote:
> >  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
> >  		CLASS(fd, f)(dfd);
> > -		if (!f.file)
> > +		if (!fd_file(f))
> 
> 		if (fd_empty(f))
> 
> actually, and similar for the rest of it.  Anyway, that'll need to be
> sorted out in vfs/vfs.git; sorry about the delay.

You should already have a never rebase branch for the basic
infrastructure. I can just merge that. But I'll just make my usual note
and just provide the required fixups when I send Linus a pr. That'll
work too. /me trying not to have his brain melted by the heat.

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hi all,

On Wed, 14 Aug 2024 11:25:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.

It looks like he bpf-next tree has lost the above commit, so I have
removed my merge fix patches.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/namespace.c: In function 'grab_requested_mnt_ns':
fs/namespace.c:5299:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5299 |                 if (!f.file)
      |                       ^
fs/namespace.c:5302:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5302 |                 if (!proc_ns_file(f.file))
      |                                    ^
In file included from fs/namespace.c:25:
fs/namespace.c:5305:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 5305 |                 ns = get_proc_ns(file_inode(f.file));
      |                                              ^
include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
   75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
      |                                                  ^~~~~

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  7b9d14af8777 ("fs: allow mount namespace fd")

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:27:11 +1000
Subject: [PATCH] fixe up for "introduce fd_file(), convert all accessors to it."

interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/namespace.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 8e88938d3f19..cad6dd5db2da 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -5296,13 +5296,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
 		struct ns_common *ns;
 
 		CLASS(fd, f)(kreq->spare);
-		if (!f.file)
+		if (!fd_file(f))
 			return ERR_PTR(-EBADF);
 
-		if (!proc_ns_file(f.file))
+		if (!proc_ns_file(fd_file(f)))
 			return ERR_PTR(-EINVAL);
 
-		ns = get_proc_ns(file_inode(f.file));
+		ns = get_proc_ns(file_inode(fd_file(f)));
 		if (ns->ops->type != CLONE_NEWNS)
 			return ERR_PTR(-EINVAL);
 
-- 
2.45.2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:


Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:40:17 +1000
Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."

interacting with commits

  1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
  278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
  5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
  33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")

from the vfs-brauner tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xattr.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index fa992953fa78..f3559ed3279f 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
 	int error;
 
 	CLASS(fd, f)(fd);
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return -EBADF;
 
 	audit_file(fd_file(f));
@@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
+		audit_file(fd_file(f));
+		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
 				name, value, size);
 	}
 
@@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
 	struct fd f = fdget(fd);
 	ssize_t error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
@@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
 
 	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
 		CLASS(fd, f)(dfd);
-		if (!f.file)
+		if (fd_empty(f))
 			return -EBADF;
-		audit_file(f.file);
-		return listxattr(file_dentry(f.file), list, size);
+		audit_file(fd_file(f));
+		return listxattr(file_dentry(fd_file(f)), list, size);
 	}
 
 	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
@@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
 	struct fd f = fdget(fd);
 	ssize_t error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 	error = listxattr(fd_file(f)->f_path.dentry, list, size);
@@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
 	int error = -EBADF;
 
 	CLASS(fd, f)(fd);
-	if (!f.file)
+	if (fd_empty(f))
 		return error;
-	audit_file(f.file);
+	audit_file(fd_file(f));
 
 	error = strncpy_from_user(kname, name, sizeof(kname));
 	if (error == 0 || error == sizeof(kname))
@@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
 	if (error < 0)
 		return error;
 
-	error = mnt_want_write_file(f.file);
+	error = mnt_want_write_file(fd_file(f));
 	if (!error) {
-		error = removexattr(file_mnt_idmap(f.file),
-				    f.file->f_path.dentry, kname);
-		mnt_drop_write_file(f.file);
+		error = removexattr(file_mnt_idmap(fd_file(f)),
+				    fd_file(f)->f_path.dentry, kname);
+		mnt_drop_write_file(fd_file(f));
 	}
 	return error;
 }
@@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
 	char kname[XATTR_NAME_MAX + 1];
 	int error = -EBADF;
 
-	if (!fd_file(f))
+	if (fd_empty(f))
 		return error;
 	audit_file(fd_file(f));
 
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 7493 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:45:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

/home/sfr/next/next/fs/xattr.c: In function 'path_getxattrat':
/home/sfr/next/next/fs/xattr.c:832:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  832 |                 if (!f.file)
      |                       ^
/home/sfr/next/next/fs/xattr.c:834:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  834 |                 audit_file(f.file);
      |                             ^
/home/sfr/next/next/fs/xattr.c:835:49: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                 ^
/home/sfr/next/next/fs/xattr.c:835:70: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  835 |                 return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
      |                                                                      ^
/home/sfr/next/next/fs/xattr.c: In function 'path_listxattrat':
/home/sfr/next/next/fs/xattr.c:952:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  952 |                 if (!f.file)
      |                       ^
/home/sfr/next/next/fs/xattr.c:954:29: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  954 |                 audit_file(f.file);
      |                             ^
/home/sfr/next/next/fs/xattr.c:955:47: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
  955 |                 return listxattr(file_dentry(f.file), list, size);
      |                                               ^
/home/sfr/next/next/fs/xattr.c: In function 'do_fremovexattr':
/home/sfr/next/next/fs/xattr.c:1021:15: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1021 |         if (!f.file) 
      |               ^
/home/sfr/next/next/fs/xattr.c:1023:21: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1023 |         audit_file(f.file);
      |                     ^
/home/sfr/next/next/fs/xattr.c:1031:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1031 |         error = mnt_want_write_file(f.file);
      |                                      ^
/home/sfr/next/next/fs/xattr.c:1033:53: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1033 |                 error = removexattr(file_mnt_idmap(f.file),
      |                                                     ^
/home/sfr/next/next/fs/xattr.c:1034:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1034 |                                     f.file->f_path.dentry, kname);
      |                                      ^
/home/sfr/next/next/fs/xattr.c:1035:38: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
 1035 |                 mnt_drop_write_file(f.file);
      |                                      ^

> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:40:17 +1000
> Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xattr.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index fa992953fa78..f3559ed3279f 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
>  	int error;
>  
>  	CLASS(fd, f)(fd);
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return -EBADF;
>  
>  	audit_file(fd_file(f));
> @@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
> +		audit_file(fd_file(f));
> +		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
>  				name, value, size);
>  	}
>  
> @@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
> @@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return listxattr(file_dentry(f.file), list, size);
> +		audit_file(fd_file(f));
> +		return listxattr(file_dentry(fd_file(f)), list, size);
>  	}
>  
>  	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> @@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = listxattr(fd_file(f)->f_path.dentry, list, size);
> @@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	int error = -EBADF;
>  
>  	CLASS(fd, f)(fd);
> -	if (!f.file)
> +	if (fd_empty(f))
>  		return error;
> -	audit_file(f.file);
> +	audit_file(fd_file(f));
>  
>  	error = strncpy_from_user(kname, name, sizeof(kname));
>  	if (error == 0 || error == sizeof(kname))
> @@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	if (error < 0)
>  		return error;
>  
> -	error = mnt_want_write_file(f.file);
> +	error = mnt_want_write_file(fd_file(f));
>  	if (!error) {
> -		error = removexattr(file_mnt_idmap(f.file),
> -				    f.file->f_path.dentry, kname);
> -		mnt_drop_write_file(f.file);
> +		error = removexattr(file_mnt_idmap(fd_file(f)),
> +				    fd_file(f)->f_path.dentry, kname);
> +		mnt_drop_write_file(fd_file(f));
>  	}
>  	return error;
>  }
> @@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
>  	char kname[XATTR_NAME_MAX + 1];
>  	int error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  
> -- 
> 2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
  938 |         if (!file1.file)
      |                   ^
fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
  940 |         fxr.file1 = file1.file;
      |                          ^

Caused by commit

  1da91ea87aef ("introduce fd_file(), convert all accessors to it.")

interacting with commit

  398597c3ef7f ("xfs: introduce new file range commit ioctls")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Sep 2024 13:53:35 +1000
Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
 it."

interacting with commit "xfs: introduce new file range commit ioctls"
from the xfs tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/xfs/xfs_exchrange.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_exchrange.c b/fs/xfs/xfs_exchrange.c
index 39fe02a8deac..75cb53f090d1 100644
--- a/fs/xfs/xfs_exchrange.c
+++ b/fs/xfs/xfs_exchrange.c
@@ -935,9 +935,9 @@ xfs_ioc_commit_range(
 	fxr.file2_ctime.tv_nsec	= kern_f->file2_ctime_nsec;
 
 	file1 = fdget(args.file1_fd);
-	if (!file1.file)
+	if (fd_empty(file1))
 		return -EBADF;
-	fxr.file1 = file1.file;
+	fxr.file1 = fd_file(file1);
 
 	error = xfs_exchange_range(&fxr);
 	fdput(file1);
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Al Viro]

On Fri, Sep 13, 2024 at 01:55:51PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
>   938 |         if (!file1.file)
>       |                   ^
> fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
>   940 |         fxr.file1 = file1.file;
>       |                          ^
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:53:35 +1000
> Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
>  it."
> 
> interacting with commit "xfs: introduce new file range commit ioctls"
> from the xfs tree.

... and the same for io_uring/rsrc.c, conflict with "io_uring: add IORING_REGISTER_COPY_BUFFERS method".

FWIW, that (sub)series is in viro/vfs.git#for-next - I forgot to put it
there, so when bpf tree reorgs had lost their branch on top of that thing,
the conflict fixes got dropped from -next.  Sorry... ;-/

Re: linux-next: build failure after merge of the bpf-next tree

[Andrii Nakryiko]

On Thu, Sep 12, 2024 at 9:00 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Sep 13, 2024 at 01:55:51PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> > fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
> >   938 |         if (!file1.file)
> >       |                   ^
> > fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
> >   940 |         fxr.file1 = file1.file;
> >       |                          ^
> >
> > Caused by commit
> >
> >   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> >
> > interacting with commit
> >
> >   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 13 Sep 2024 13:53:35 +1000
> > Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
> >  it."
> >
> > interacting with commit "xfs: introduce new file range commit ioctls"
> > from the xfs tree.
>
> ... and the same for io_uring/rsrc.c, conflict with "io_uring: add IORING_REGISTER_COPY_BUFFERS method".
>
> FWIW, that (sub)series is in viro/vfs.git#for-next - I forgot to put it
> there, so when bpf tree reorgs had lost their branch on top of that thing,
> the conflict fixes got dropped from -next.  Sorry... ;-/

Should I take out the following from bpf-next/for-next for now?

a8e40fd0f127 ("Merge branch 'bpf-next/struct_fd' into for-next")

Al, currently I'm basing my patches on top of your stable-struct_fd
branch. If you need to update it, I think that's fine, I can rebase on
top of the updated branch, given my patches weren't yet merged
anywhere. Let me know.

Re: linux-next: build failure after merge of the bpf-next tree

[Al Viro]

On Thu, Sep 12, 2024 at 09:26:31PM -0700, Andrii Nakryiko wrote:

> Should I take out the following from bpf-next/for-next for now?
> 
> a8e40fd0f127 ("Merge branch 'bpf-next/struct_fd' into for-next")
> 
> Al, currently I'm basing my patches on top of your stable-struct_fd
> branch. If you need to update it, I think that's fine, I can rebase on
> top of the updated branch, given my patches weren't yet merged
> anywhere. Let me know.

al@duke:~/linux/trees/temp$ git describe for-next 
v6.11-rc1-3-gde12c3391bce
al@duke:~/linux/trees/temp$ git describe stable-struct_fd 
v6.11-rc1-3-gde12c3391bce

IOW, #for-next is currently identical to that branch (will grow a merge
shortly); no need to rebase anything.

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:32:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/namespace.c: In function 'grab_requested_mnt_ns':
> fs/namespace.c:5299:23: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5299 |                 if (!f.file)
>       |                       ^
> fs/namespace.c:5302:36: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5302 |                 if (!proc_ns_file(f.file))
>       |                                    ^
> In file included from fs/namespace.c:25:
> fs/namespace.c:5305:46: error: 'class_fd_t' {aka 'struct fd'} has no member named 'file'
>  5305 |                 ns = get_proc_ns(file_inode(f.file));
>       |                                              ^
> include/linux/proc_ns.h:75:50: note: in definition of macro 'get_proc_ns'
>    75 | #define get_proc_ns(inode) ((struct ns_common *)(inode)->i_private)
>       |                                                  ^~~~~
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   7b9d14af8777 ("fs: allow mount namespace fd")
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:27:11 +1000
> Subject: [PATCH] fixe up for "introduce fd_file(), convert all accessors to it."
> 
> interacting with "fs: allow mount namespace fd" from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/namespace.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 8e88938d3f19..cad6dd5db2da 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -5296,13 +5296,13 @@ static struct mnt_namespace *grab_requested_mnt_ns(const struct mnt_id_req *kreq
>  		struct ns_common *ns;
>  
>  		CLASS(fd, f)(kreq->spare);
> -		if (!f.file)
> +		if (!fd_file(f))
>  			return ERR_PTR(-EBADF);
>  
> -		if (!proc_ns_file(f.file))
> +		if (!proc_ns_file(fd_file(f)))
>  			return ERR_PTR(-EINVAL);
>  
> -		ns = get_proc_ns(file_inode(f.file));
> +		ns = get_proc_ns(file_inode(fd_file(f)));
>  		if (ns->ops->type != CLONE_NEWNS)
>  			return ERR_PTR(-EINVAL);
>  
> -- 
> 2.45.2
> 

This is now required in the merge of the vfs tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4693 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:45:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:40:17 +1000
> Subject: [PATCH] fix up 2 for "introduce fd_file(), convert all accessors to it."
> 
> interacting with commits
> 
>   1a61c9d6ec1d ("xattr: handle AT_EMPTY_PATH when setting xattrs")
>   278397b2c592 ("xattr: handle AT_EMPTY_PATH when getting xattrs")
>   5560ab7ee32e ("xattr: handle AT_EMPTY_PATH when listing xattrs")
>   33fce6444e7d ("xattr: handle AT_EMPTY_PATH when removing xattrs")
> 
> from the vfs-brauner tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xattr.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/fs/xattr.c b/fs/xattr.c
> index fa992953fa78..f3559ed3279f 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -645,7 +645,7 @@ static int do_fsetxattr(int fd, const char __user *name,
>  	int error;
>  
>  	CLASS(fd, f)(fd);
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return -EBADF;
>  
>  	audit_file(fd_file(f));
> @@ -829,10 +829,10 @@ static ssize_t path_getxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return getxattr(file_mnt_idmap(f.file), file_dentry(f.file),
> +		audit_file(fd_file(f));
> +		return getxattr(file_mnt_idmap(fd_file(f)), file_dentry(fd_file(f)),
>  				name, value, size);
>  	}
>  
> @@ -895,7 +895,7 @@ SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name,
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = getxattr(file_mnt_idmap(fd_file(f)), fd_file(f)->f_path.dentry,
> @@ -949,10 +949,10 @@ static ssize_t path_listxattrat(int dfd, const char __user *pathname,
>  
>  	if (at_flags & AT_EMPTY_PATH && vfs_empty_path(dfd, pathname)) {
>  		CLASS(fd, f)(dfd);
> -		if (!f.file)
> +		if (fd_empty(f))
>  			return -EBADF;
> -		audit_file(f.file);
> -		return listxattr(file_dentry(f.file), list, size);
> +		audit_file(fd_file(f));
> +		return listxattr(file_dentry(fd_file(f)), list, size);
>  	}
>  
>  	lookup_flags = (at_flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> @@ -993,7 +993,7 @@ SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size)
>  	struct fd f = fdget(fd);
>  	ssize_t error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  	error = listxattr(fd_file(f)->f_path.dentry, list, size);
> @@ -1018,9 +1018,9 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	int error = -EBADF;
>  
>  	CLASS(fd, f)(fd);
> -	if (!f.file)
> +	if (fd_empty(f))
>  		return error;
> -	audit_file(f.file);
> +	audit_file(fd_file(f));
>  
>  	error = strncpy_from_user(kname, name, sizeof(kname));
>  	if (error == 0 || error == sizeof(kname))
> @@ -1028,11 +1028,11 @@ static int do_fremovexattr(int fd, const char __user *name)
>  	if (error < 0)
>  		return error;
>  
> -	error = mnt_want_write_file(f.file);
> +	error = mnt_want_write_file(fd_file(f));
>  	if (!error) {
> -		error = removexattr(file_mnt_idmap(f.file),
> -				    f.file->f_path.dentry, kname);
> -		mnt_drop_write_file(f.file);
> +		error = removexattr(file_mnt_idmap(fd_file(f)),
> +				    fd_file(f)->f_path.dentry, kname);
> +		mnt_drop_write_file(fd_file(f));
>  	}
>  	return error;
>  }
> @@ -1099,7 +1099,7 @@ SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name)
>  	char kname[XATTR_NAME_MAX + 1];
>  	int error = -EBADF;
>  
> -	if (!fd_file(f))
> +	if (fd_empty(f))
>  		return error;
>  	audit_file(fd_file(f));
>  
> -- 
> 2.45.2

This is not longer required as the above commits have been removed from
the vfs-brauner tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hi all,

On Fri, 13 Sep 2024 13:55:51 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/xfs/xfs_exchrange.c: In function 'xfs_ioc_commit_range':
> fs/xfs/xfs_exchrange.c:938:19: error: 'struct fd' has no member named 'file'
>   938 |         if (!file1.file)
>       |                   ^
> fs/xfs/xfs_exchrange.c:940:26: error: 'struct fd' has no member named 'file'
>   940 |         fxr.file1 = file1.file;
>       |                          ^
> 
> Caused by commit
> 
>   1da91ea87aef ("introduce fd_file(), convert all accessors to it.")
> 
> interacting with commit
> 
>   398597c3ef7f ("xfs: introduce new file range commit ioctls")
> 
> I have applied the following patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 Sep 2024 13:53:35 +1000
> Subject: [PATCH] fix up 3 for "introduce fd_file(), convert all accessors to
>  it."
> 
> interacting with commit "xfs: introduce new file range commit ioctls"
> from the xfs tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/xfs/xfs_exchrange.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/xfs/xfs_exchrange.c b/fs/xfs/xfs_exchrange.c
> index 39fe02a8deac..75cb53f090d1 100644
> --- a/fs/xfs/xfs_exchrange.c
> +++ b/fs/xfs/xfs_exchrange.c
> @@ -935,9 +935,9 @@ xfs_ioc_commit_range(
>  	fxr.file2_ctime.tv_nsec	= kern_f->file2_ctime_nsec;
>  
>  	file1 = fdget(args.file1_fd);
> -	if (!file1.file)
> +	if (fd_empty(file1))
>  		return -EBADF;
> -	fxr.file1 = file1.file;
> +	fxr.file1 = fd_file(file1);
>  
>  	error = xfs_exchange_range(&fxr);
>  	fdput(file1);
> -- 
> 2.45.2

This is now required in the merge of the vfs tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (arm64
defconfig) failed like this:

Building: arm64 defconfig
In file included from arch/arm64/include/asm/thread_info.h:17,
                 from include/linux/thread_info.h:60,
                 from arch/arm64/include/asm/preempt.h:6,
                 from include/linux/preempt.h:79,
                 from include/linux/spinlock.h:56,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:7,
                 from include/linux/slab.h:16,
                 from mm/slab_common.c:7:
mm/slab_common.c: In function 'bpf_get_kmem_cache':
arch/arm64/include/asm/memory.h:427:66: error: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
  427 |         __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));      \
      |                                                                  ^~~~~~
      |                                                                  |
      |                                                                  u64 {aka long long unsigned int}
mm/slab_common.c:1260:14: note: in expansion of macro 'virt_addr_valid'
 1260 |         if (!virt_addr_valid(addr))
      |              ^~~~~~~~~~~~~~~
arch/arm64/include/asm/memory.h:382:53: note: expected 'const void *' but argument is of type 'u64' {aka 'long long unsigned int'}
  382 | static inline unsigned long virt_to_pfn(const void *kaddr)
      |                                         ~~~~~~~~~~~~^~~~~

Caused by commit

  04b069ff0181 ("mm/bpf: Add bpf_get_kmem_cache() kfunc")

I have reverted commit

  08c837461891 ("Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'")

for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Tue, Oct 15, 2024 at 11:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm64
> defconfig) failed like this:
>
> Building: arm64 defconfig
> In file included from arch/arm64/include/asm/thread_info.h:17,
>                  from include/linux/thread_info.h:60,
>                  from arch/arm64/include/asm/preempt.h:6,
>                  from include/linux/preempt.h:79,
>                  from include/linux/spinlock.h:56,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:7,
>                  from include/linux/slab.h:16,
>                  from mm/slab_common.c:7:
> mm/slab_common.c: In function 'bpf_get_kmem_cache':
> arch/arm64/include/asm/memory.h:427:66: error: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
>   427 |         __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));      \
>       |                                                                  ^~~~~~
>       |                                                                  |
>       |                                                                  u64 {aka long long unsigned int}
> mm/slab_common.c:1260:14: note: in expansion of macro 'virt_addr_valid'
>  1260 |         if (!virt_addr_valid(addr))
>       |              ^~~~~~~~~~~~~~~
> arch/arm64/include/asm/memory.h:382:53: note: expected 'const void *' but argument is of type 'u64' {aka 'long long unsigned int'}
>   382 | static inline unsigned long virt_to_pfn(const void *kaddr)
>       |                                         ~~~~~~~~~~~~^~~~~
>
> Caused by commit
>
>   04b069ff0181 ("mm/bpf: Add bpf_get_kmem_cache() kfunc")
>
> I have reverted commit
>
>   08c837461891 ("Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'")
>
> for today.

Thanks for flagging.
Fixed and force pushed.

Re: linux-next: build failure after merge of the bpf-next tree

[Namhyung Kim]

On Wed, Oct 16, 2024 at 09:25:41AM -0700, Alexei Starovoitov wrote:
> On Tue, Oct 15, 2024 at 11:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (arm64
> > defconfig) failed like this:
> >
> > Building: arm64 defconfig
> > In file included from arch/arm64/include/asm/thread_info.h:17,
> >                  from include/linux/thread_info.h:60,
> >                  from arch/arm64/include/asm/preempt.h:6,
> >                  from include/linux/preempt.h:79,
> >                  from include/linux/spinlock.h:56,
> >                  from include/linux/mmzone.h:8,
> >                  from include/linux/gfp.h:7,
> >                  from include/linux/slab.h:16,
> >                  from mm/slab_common.c:7:
> > mm/slab_common.c: In function 'bpf_get_kmem_cache':
> > arch/arm64/include/asm/memory.h:427:66: error: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
> >   427 |         __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));      \
> >       |                                                                  ^~~~~~
> >       |                                                                  |
> >       |                                                                  u64 {aka long long unsigned int}
> > mm/slab_common.c:1260:14: note: in expansion of macro 'virt_addr_valid'
> >  1260 |         if (!virt_addr_valid(addr))
> >       |              ^~~~~~~~~~~~~~~
> > arch/arm64/include/asm/memory.h:382:53: note: expected 'const void *' but argument is of type 'u64' {aka 'long long unsigned int'}
> >   382 | static inline unsigned long virt_to_pfn(const void *kaddr)
> >       |                                         ~~~~~~~~~~~~^~~~~
> >
> > Caused by commit
> >
> >   04b069ff0181 ("mm/bpf: Add bpf_get_kmem_cache() kfunc")
> >
> > I have reverted commit
> >
> >   08c837461891 ("Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'")
> >
> > for today.
> 
> Thanks for flagging.
> Fixed and force pushed.

Oops, thanks for fixing this.  The virt_addr_valid() was confusing
whether it takes unsigned long or a pointer.  It seems each arch has
different expectation.

Thanks,
Namhyung

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Wed, Oct 16, 2024 at 11:35 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Wed, Oct 16, 2024 at 09:25:41AM -0700, Alexei Starovoitov wrote:
> > On Tue, Oct 15, 2024 at 11:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (arm64
> > > defconfig) failed like this:
> > >
> > > Building: arm64 defconfig
> > > In file included from arch/arm64/include/asm/thread_info.h:17,
> > >                  from include/linux/thread_info.h:60,
> > >                  from arch/arm64/include/asm/preempt.h:6,
> > >                  from include/linux/preempt.h:79,
> > >                  from include/linux/spinlock.h:56,
> > >                  from include/linux/mmzone.h:8,
> > >                  from include/linux/gfp.h:7,
> > >                  from include/linux/slab.h:16,
> > >                  from mm/slab_common.c:7:
> > > mm/slab_common.c: In function 'bpf_get_kmem_cache':
> > > arch/arm64/include/asm/memory.h:427:66: error: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion]
> > >   427 |         __is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));      \
> > >       |                                                                  ^~~~~~
> > >       |                                                                  |
> > >       |                                                                  u64 {aka long long unsigned int}
> > > mm/slab_common.c:1260:14: note: in expansion of macro 'virt_addr_valid'
> > >  1260 |         if (!virt_addr_valid(addr))
> > >       |              ^~~~~~~~~~~~~~~
> > > arch/arm64/include/asm/memory.h:382:53: note: expected 'const void *' but argument is of type 'u64' {aka 'long long unsigned int'}
> > >   382 | static inline unsigned long virt_to_pfn(const void *kaddr)
> > >       |                                         ~~~~~~~~~~~~^~~~~
> > >
> > > Caused by commit
> > >
> > >   04b069ff0181 ("mm/bpf: Add bpf_get_kmem_cache() kfunc")
> > >
> > > I have reverted commit
> > >
> > >   08c837461891 ("Merge branch 'bpf-add-kmem_cache-iterator-and-kfunc'")
> > >
> > > for today.
> >
> > Thanks for flagging.
> > Fixed and force pushed.
>
> Oops, thanks for fixing this.  The virt_addr_valid() was confusing
> whether it takes unsigned long or a pointer.  It seems each arch has
> different expectation.

        if (!virt_addr_valid((void *)(long)addr))

did the trick for me and that's what I pushed.
Odd that our bpf CI on arm64 didn't catch it.

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5745 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/asm-generic/percpu.h:7,
                 from arch/powerpc/include/asm/percpu.h:28,
                 from arch/powerpc/include/asm/smp.h:26,
                 from include/linux/smp.h:119,
                 from include/linux/lockdep.h:14,
                 from include/linux/radix-tree.h:14,
                 from include/linux/idr.h:15,
                 from include/linux/cgroup-defs.h:13,
                 from mm/memcontrol.c:28:
mm/memcontrol.c: In function 'memcg_hotplug_cpu_dead':
include/linux/percpu-defs.h:242:2: error: passing argument 1 of 'local_lock_acquire' from incompatible pointer type [-Wincompatible-pointer-types]
  242 | ({                                                                      \
      | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  |
      |  localtry_lock_t *
  243 |         __verify_pcpu_ptr(ptr);                                         \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  244 |         arch_raw_cpu_ptr(ptr);                                          \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  245 | })
      | ~~
include/linux/percpu-defs.h:254:27: note: in expansion of macro 'raw_cpu_ptr'
  254 | #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
      |                           ^~~~~~~~~~~
include/linux/local_lock_internal.h:105:36: note: in expansion of macro 'this_cpu_ptr'
  105 |                 local_lock_acquire(this_cpu_ptr(lock));         \
      |                                    ^~~~~~~~~~~~
include/linux/local_lock.h:31:9: note: in expansion of macro '__local_lock_irqsave'
   31 |         __local_lock_irqsave(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~
mm/memcontrol.c:1960:9: note: in expansion of macro 'local_lock_irqsave'
 1960 |         local_lock_irqsave(&memcg_stock.stock_lock, flags);
      |         ^~~~~~~~~~~~~~~~~~
In file included from include/linux/local_lock.h:5,
                 from include/linux/mmzone.h:24,
                 from include/linux/gfp.h:7,
                 from include/linux/xarray.h:16,
                 from include/linux/radix-tree.h:21:
include/linux/local_lock_internal.h:59:53: note: expected 'local_lock_t *' but argument is of type 'localtry_lock_t *'
   59 | static inline void local_lock_acquire(local_lock_t *l) { }
      |                                       ~~~~~~~~~~~~~~^
include/linux/percpu-defs.h:242:2: error: passing argument 1 of 'local_lock_release' from incompatible pointer type [-Wincompatible-pointer-types]
  242 | ({                                                                      \
      | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |  |
      |  localtry_lock_t *
  243 |         __verify_pcpu_ptr(ptr);                                         \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  244 |         arch_raw_cpu_ptr(ptr);                                          \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  245 | })
      | ~~
include/linux/percpu-defs.h:254:27: note: in expansion of macro 'raw_cpu_ptr'
  254 | #define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
      |                           ^~~~~~~~~~~
include/linux/local_lock_internal.h:122:36: note: in expansion of macro 'this_cpu_ptr'
  122 |                 local_lock_release(this_cpu_ptr(lock));         \
      |                                    ^~~~~~~~~~~~
include/linux/local_lock.h:52:9: note: in expansion of macro '__local_unlock_irqrestore'
   52 |         __local_unlock_irqrestore(lock, flags)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
mm/memcontrol.c:1962:9: note: in expansion of macro 'local_unlock_irqrestore'
 1962 |         local_unlock_irqrestore(&memcg_stock.stock_lock, flags);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
include/linux/local_lock_internal.h:61:53: note: expected 'local_lock_t *' but argument is of type 'localtry_lock_t *'
   61 | static inline void local_lock_release(local_lock_t *l) { }
      |                                       ~~~~~~~~~~~~~~^

Caused by commits

  0aaddfb06882 ("locking/local_lock: Introduce localtry_lock_t")
  01d37228d331 ("memcg: Use trylock to access memcg stock_lock.")

interacting with commit

  885aa5fe7b1d ("memcg: drain obj stock on cpu hotplug teardown")

from the mm-hotfixes tree.

I applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Mar 2025 14:18:03 +1100
Subject: [PATCH] fix up for "memcg: Use trylock to access memcg stock_lock"

interacting with "memcg: drain obj stock on cpu hotplug teardown" from
the mm-hotfixes tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/memcontrol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8f88b8dd8097..87544df4c3b8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1957,9 +1957,9 @@ static int memcg_hotplug_cpu_dead(unsigned int cpu)
 	stock = &per_cpu(memcg_stock, cpu);
 
 	/* drain_obj_stock requires stock_lock */
-	local_lock_irqsave(&memcg_stock.stock_lock, flags);
+	localtry_lock_irqsave(&memcg_stock.stock_lock, flags);
 	old = drain_obj_stock(stock);
-	local_unlock_irqrestore(&memcg_stock.stock_lock, flags);
+	localtry_unlock_irqrestore(&memcg_stock.stock_lock, flags);
 
 	drain_stock(stock);
 	obj_cgroup_put(old);
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/asm-generic/percpu.h:7,
                 from arch/x86/include/asm/percpu.h:630,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:79,
                 from include/linux/smp.h:116,
                 from kernel/locking/qspinlock.c:16:
kernel/locking/qspinlock.h: In function 'decode_tail':
include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
  219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
      |                                             ^
include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
  237 |         __verify_pcpu_ptr(ptr);                                         \
      |         ^~~~~~~~~~~~~~~~~
kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
   67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
      |                ^~~~~~~~~~~
include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
  219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
      |                                             ^
include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
  237 |         __verify_pcpu_ptr(ptr);                                         \
      |         ^~~~~~~~~~~~~~~~~
kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
   67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
      |                ^~~~~~~~~~~
kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
  285 |                 prev = decode_tail(old, qnodes);
      |                                         ^~~~~~
In file included from kernel/locking/qspinlock.c:30:
kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
   62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
      |                                                                 ~~~~~~~~~~~~~~^~~~~~
In file included from kernel/locking/qspinlock.c:401:
kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
  285 |                 prev = decode_tail(old, qnodes);
      |                                         ^~~~~~
kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
   62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
      |                                                                 ~~~~~~~~~~~~~~^~~~~~

Caused by the resilient-queued-spin-lock branch of the bpf-next tree
interacting with the "Enable strict percpu address space checks" series
form the mm-stable tree.

I don't know why this happens, but reverting that branch inf the bpf-next
tree makes the failure go away, so I have done that for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/asm-generic/percpu.h:7,
>                  from arch/x86/include/asm/percpu.h:630,
>                  from arch/x86/include/asm/preempt.h:6,
>                  from include/linux/preempt.h:79,
>                  from include/linux/smp.h:116,
>                  from kernel/locking/qspinlock.c:16:
> kernel/locking/qspinlock.h: In function 'decode_tail':
> include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
>   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
>       |                                             ^
> include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
>   237 |         __verify_pcpu_ptr(ptr);                                         \
>       |         ^~~~~~~~~~~~~~~~~
> kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
>    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
>       |                ^~~~~~~~~~~
> include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
>   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
>       |                                             ^
> include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
>   237 |         __verify_pcpu_ptr(ptr);                                         \
>       |         ^~~~~~~~~~~~~~~~~
> kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
>    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
>       |                ^~~~~~~~~~~
> kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
> kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
>   285 |                 prev = decode_tail(old, qnodes);
>       |                                         ^~~~~~
> In file included from kernel/locking/qspinlock.c:30:
> kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
>    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
>       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> In file included from kernel/locking/qspinlock.c:401:
> kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
> kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
>   285 |                 prev = decode_tail(old, qnodes);
>       |                                         ^~~~~~
> kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
>    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
>       |                                                                 ~~~~~~~~~~~~~~^~~~~~
>
> Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> interacting with the "Enable strict percpu address space checks" series
> form the mm-stable tree.

Do you mean this set:
https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@gmail.com/

>
> I don't know why this happens, but reverting that branch inf the bpf-next
> tree makes the failure go away, so I have done that for today.

Kumar,

pls take a look.

Re: linux-next: build failure after merge of the bpf-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Hi Alexei,

On Tue, 18 Mar 2025 19:46:52 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> > interacting with the "Enable strict percpu address space checks" series
> > form the mm-stable tree.  
> 
> Do you mean this set:
> https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@gmail.com/

Yes.  Also available as commits up to commit

 6a367577153a ("percpu/x86: enable strict percpu checks via named AS qualifiers")

in the mm-stable branch of the mm tree
(git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm#mm-stable) and
yesterday's linux-next tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Uros Bizjak]

On Wed, Mar 19, 2025 at 3:33 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> interacting with the "Enable strict percpu address space checks" series
> form the mm-stable tree.
>
> I don't know why this happens, but reverting that branch inf the bpf-next
> tree makes the failure go away, so I have done that for today.

percpu pointers are now checked by the compiler, and their address
spaces have to be handled properly. It is like "sparse" rule, but now
enforced by the compiler.

This functionality was in fact introduced to catch programming errors like this.

Thanks,
Uros.

Re: linux-next: build failure after merge of the bpf-next tree

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/asm-generic/percpu.h:7,
> >                  from arch/x86/include/asm/percpu.h:630,
> >                  from arch/x86/include/asm/preempt.h:6,
> >                  from include/linux/preempt.h:79,
> >                  from include/linux/smp.h:116,
> >                  from kernel/locking/qspinlock.c:16:
> > kernel/locking/qspinlock.h: In function 'decode_tail':
> > include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
> >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> >       |                                             ^
> > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> >   237 |         __verify_pcpu_ptr(ptr);                                         \
> >       |         ^~~~~~~~~~~~~~~~~
> > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> >       |                ^~~~~~~~~~~
> > include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
> >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> >       |                                             ^
> > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> >   237 |         __verify_pcpu_ptr(ptr);                                         \
> >       |         ^~~~~~~~~~~~~~~~~
> > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> >       |                ^~~~~~~~~~~
> > kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
> > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> >   285 |                 prev = decode_tail(old, qnodes);
> >       |                                         ^~~~~~
> > In file included from kernel/locking/qspinlock.c:30:
> > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > In file included from kernel/locking/qspinlock.c:401:
> > kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
> > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> >   285 |                 prev = decode_tail(old, qnodes);
> >       |                                         ^~~~~~
> > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> >
> > Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> > interacting with the "Enable strict percpu address space checks" series
> > form the mm-stable tree.
>
> Do you mean this set:
> https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@gmail.com/
>
> >
> > I don't know why this happens, but reverting that branch inf the bpf-next
> > tree makes the failure go away, so I have done that for today.
>
> Kumar,
>
> pls take a look.

I've sent a fix [0], but unfortunately I was unable to reproduce the
problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
as the patches require to confirm, but based on the error I am 99%
sure it will fix the problem.

[0] https://lore.kernel.org/bpf/20250319133523.641009-1-memxor@gmail.com

Feel free to cherry-pick or squash into the fixed commit, whatever is best.

Re: linux-next: build failure after merge of the bpf-next tree

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 14:37, Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
>
> On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > In file included from include/asm-generic/percpu.h:7,
> > >                  from arch/x86/include/asm/percpu.h:630,
> > >                  from arch/x86/include/asm/preempt.h:6,
> > >                  from include/linux/preempt.h:79,
> > >                  from include/linux/smp.h:116,
> > >                  from kernel/locking/qspinlock.c:16:
> > > kernel/locking/qspinlock.h: In function 'decode_tail':
> > > include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
> > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > >       |                                             ^
> > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > >       |         ^~~~~~~~~~~~~~~~~
> > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > >       |                ^~~~~~~~~~~
> > > include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
> > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > >       |                                             ^
> > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > >       |         ^~~~~~~~~~~~~~~~~
> > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > >       |                ^~~~~~~~~~~
> > > kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
> > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > >   285 |                 prev = decode_tail(old, qnodes);
> > >       |                                         ^~~~~~
> > > In file included from kernel/locking/qspinlock.c:30:
> > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > > In file included from kernel/locking/qspinlock.c:401:
> > > kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
> > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > >   285 |                 prev = decode_tail(old, qnodes);
> > >       |                                         ^~~~~~
> > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > >
> > > Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> > > interacting with the "Enable strict percpu address space checks" series
> > > form the mm-stable tree.
> >
> > Do you mean this set:
> > https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@gmail.com/
> >
> > >
> > > I don't know why this happens, but reverting that branch inf the bpf-next
> > > tree makes the failure go away, so I have done that for today.
> >
> > Kumar,
> >
> > pls take a look.
>
> I've sent a fix [0], but unfortunately I was unable to reproduce the
> problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> as the patches require to confirm, but based on the error I am 99%
> sure it will fix the problem.

Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
Let me give it a go with GCC.

>
> [0] https://lore.kernel.org/bpf/20250319133523.641009-1-memxor@gmail.com
>
> Feel free to cherry-pick or squash into the fixed commit, whatever is best.

Re: linux-next: build failure after merge of the bpf-next tree

[Kumar Kartikeya Dwivedi]

On Wed, 19 Mar 2025 at 14:43, Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
>
> On Wed, 19 Mar 2025 at 14:37, Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
> >
> > On Wed, 19 Mar 2025 at 03:47, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Tue, Mar 18, 2025 at 7:33 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > After merging the bpf-next tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > In file included from include/asm-generic/percpu.h:7,
> > > >                  from arch/x86/include/asm/percpu.h:630,
> > > >                  from arch/x86/include/asm/preempt.h:6,
> > > >                  from include/linux/preempt.h:79,
> > > >                  from include/linux/smp.h:116,
> > > >                  from kernel/locking/qspinlock.c:16:
> > > > kernel/locking/qspinlock.h: In function 'decode_tail':
> > > > include/linux/percpu-defs.h:219:45: error: initialization from pointer to non-enclosed address space
> > > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > > >       |                                             ^
> > > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > > >       |         ^~~~~~~~~~~~~~~~~
> > > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > > >       |                ^~~~~~~~~~~
> > > > include/linux/percpu-defs.h:219:45: note: expected 'const __seg_gs void *' but pointer is of type 'struct mcs_spinlock *'
> > > >   219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
> > > >       |                                             ^
> > > > include/linux/percpu-defs.h:237:9: note: in expansion of macro '__verify_pcpu_ptr'
> > > >   237 |         __verify_pcpu_ptr(ptr);                                         \
> > > >       |         ^~~~~~~~~~~~~~~~~
> > > > kernel/locking/qspinlock.h:67:16: note: in expansion of macro 'per_cpu_ptr'
> > > >    67 |         return per_cpu_ptr(&qnodes[idx].mcs, cpu);
> > > >       |                ^~~~~~~~~~~
> > > > kernel/locking/qspinlock.c: In function 'native_queued_spin_lock_slowpath':
> > > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > > >   285 |                 prev = decode_tail(old, qnodes);
> > > >       |                                         ^~~~~~
> > > > In file included from kernel/locking/qspinlock.c:30:
> > > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > > > In file included from kernel/locking/qspinlock.c:401:
> > > > kernel/locking/qspinlock.c: In function '__pv_queued_spin_lock_slowpath':
> > > > kernel/locking/qspinlock.c:285:41: error: passing argument 2 of 'decode_tail' from pointer to non-enclosed address space
> > > >   285 |                 prev = decode_tail(old, qnodes);
> > > >       |                                         ^~~~~~
> > > > kernel/locking/qspinlock.h:62:79: note: expected 'struct qnode *' but argument is of type '__seg_gs struct qnode *'
> > > >    62 | static inline __pure struct mcs_spinlock *decode_tail(u32 tail, struct qnode *qnodes)
> > > >       |                                                                 ~~~~~~~~~~~~~~^~~~~~
> > > >
> > > > Caused by the resilient-queued-spin-lock branch of the bpf-next tree
> > > > interacting with the "Enable strict percpu address space checks" series
> > > > form the mm-stable tree.
> > >
> > > Do you mean this set:
> > > https://lore.kernel.org/all/20250127160709.80604-1-ubizjak@gmail.com/
> > >
> > > >
> > > > I don't know why this happens, but reverting that branch inf the bpf-next
> > > > tree makes the failure go away, so I have done that for today.
> > >
> > > Kumar,
> > >
> > > pls take a look.
> >
> > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > as the patches require to confirm, but based on the error I am 99%
> > sure it will fix the problem.
>
> Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> Let me give it a go with GCC.
>

Can confirm now that this fixes it, I just did a build with GCC 14
where Uros's __percpu checks kick in.

> >
> > [0] https://lore.kernel.org/bpf/20250319133523.641009-1-memxor@gmail.com
> >
> > Feel free to cherry-pick or squash into the fixed commit, whatever is best.

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
> > >
> > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > as the patches require to confirm, but based on the error I am 99%
> > > sure it will fix the problem.
> >
> > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > Let me give it a go with GCC.
> >
>
> Can confirm now that this fixes it, I just did a build with GCC 14
> where Uros's __percpu checks kick in.

Great. Thanks for checking and quick fix.

btw clang supports it with __attribute__((address_space(256))),
so CC_IS_GCC probably should be relaxed.

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 7:55 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> > > >
> > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > as the patches require to confirm, but based on the error I am 99%
> > > > sure it will fix the problem.
> > >
> > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > Let me give it a go with GCC.
> > >
> >
> > Can confirm now that this fixes it, I just did a build with GCC 14
> > where Uros's __percpu checks kick in.
>
> Great. Thanks for checking and quick fix.
>
> btw clang supports it with __attribute__((address_space(256))),
> so CC_IS_GCC probably should be relaxed.

Stephen,

bpf-next/for-next is force pushed with the fix.

Thank you for flagging it quickly! Appreciate it.

Re: linux-next: build failure after merge of the bpf-next tree

[Uros Bizjak]

On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> > > >
> > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > as the patches require to confirm, but based on the error I am 99%
> > > > sure it will fix the problem.
> > >
> > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > Let me give it a go with GCC.
> > >
> >
> > Can confirm now that this fixes it, I just did a build with GCC 14
> > where Uros's __percpu checks kick in.
>
> Great. Thanks for checking and quick fix.
>
> btw clang supports it with __attribute__((address_space(256))),
> so CC_IS_GCC probably should be relaxed.

https://github.com/llvm/llvm-project/issues/93449

needs to be fixed first. Also, the feature has to be thoroughly tested
(preferably by someone having a deep knowledge of clang) before it is
enabled by default.

Thanks,
Uros.

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> > >
> > > > >
> > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > > as the patches require to confirm, but based on the error I am 99%
> > > > > sure it will fix the problem.
> > > >
> > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > > Let me give it a go with GCC.
> > > >
> > >
> > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > where Uros's __percpu checks kick in.
> >
> > Great. Thanks for checking and quick fix.
> >
> > btw clang supports it with __attribute__((address_space(256))),
> > so CC_IS_GCC probably should be relaxed.
>
> https://github.com/llvm/llvm-project/issues/93449
>
> needs to be fixed first. Also, the feature has to be thoroughly tested
> (preferably by someone having a deep knowledge of clang) before it is
> enabled by default.

clang error makes sense to me.
What does it even mean to do addr space cast from percpu to normal address:

__typeof__(int __seg_gs) const_pcpu_hot;
void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
    (void *)(long)&const_pcpu_hot;

I'm curious what kind of code gcc generates.

In bpf backend we have the concept of address spaces and there are explicit
instructions generated to convert from one addr space to another.

Re: linux-next: build failure after merge of the bpf-next tree

[Uros Bizjak]

On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > <memxor@gmail.com> wrote:
> > > >
> > > > > >
> > > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > > > as the patches require to confirm, but based on the error I am 99%
> > > > > > sure it will fix the problem.
> > > > >
> > > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > > > Let me give it a go with GCC.
> > > > >
> > > >
> > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > where Uros's __percpu checks kick in.
> > >
> > > Great. Thanks for checking and quick fix.
> > >
> > > btw clang supports it with __attribute__((address_space(256))),
> > > so CC_IS_GCC probably should be relaxed.
> >
> > https://github.com/llvm/llvm-project/issues/93449
> >
> > needs to be fixed first. Also, the feature has to be thoroughly tested
> > (preferably by someone having a deep knowledge of clang) before it is
> > enabled by default.
>
> clang error makes sense to me.

It is not an error, but an internal compiler error. This should never happen.

> What does it even mean to do addr space cast from percpu to normal address:
>
> __typeof__(int __seg_gs) const_pcpu_hot;
> void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
>     (void *)(long)&const_pcpu_hot;

Please see [1] for an explanation.

[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces

Uros.

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > <memxor@gmail.com> wrote:
> > > > >
> > > > > > >
> > > > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > > > > as the patches require to confirm, but based on the error I am 99%
> > > > > > > sure it will fix the problem.
> > > > > >
> > > > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > > > > Let me give it a go with GCC.
> > > > > >
> > > > >
> > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > where Uros's __percpu checks kick in.
> > > >
> > > > Great. Thanks for checking and quick fix.
> > > >
> > > > btw clang supports it with __attribute__((address_space(256))),
> > > > so CC_IS_GCC probably should be relaxed.
> > >
> > > https://github.com/llvm/llvm-project/issues/93449
> > >
> > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > (preferably by someone having a deep knowledge of clang) before it is
> > > enabled by default.
> >
> > clang error makes sense to me.
>
> It is not an error, but an internal compiler error. This should never happen.

Not quite. llvm backends don't have a good way to explain the error,
but this is invalid condition.
Arguably llvm should do a better job in such cases instead of
printing stack trace.

>
> > What does it even mean to do addr space cast from percpu to normal address:
> >
> > __typeof__(int __seg_gs) const_pcpu_hot;
> > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> >     (void *)(long)&const_pcpu_hot;
>
> Please see [1] for an explanation.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces

You didn't answer my question.

As suspected, gcc is producing garbage code.

See:
https://godbolt.org/z/ozozYY3nv

For
void *ptr = (void *)(long)&pcpu_hot;

gcc emits
.quad pcpu_hot
which is nonsensical, while clang refuses to produce garbage
and dumps stack.

Sadly, both compilers produce garbage for ret_addr()

and both compilers produce correct code for ret_value().
At least something.

Uros,
your percpu code is broken.
you shouldn't rely on gcc producing garbage.
Sooner or later gcc will start erroring on it just as clang.

Re: linux-next: build failure after merge of the bpf-next tree

[Uros Bizjak]

On Thu, Mar 20, 2025 at 12:17 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > > <memxor@gmail.com> wrote:
> > > > > >
> > > > > > > >
> > > > > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > > > > > as the patches require to confirm, but based on the error I am 99%
> > > > > > > > sure it will fix the problem.
> > > > > > >
> > > > > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > > > > > Let me give it a go with GCC.
> > > > > > >
> > > > > >
> > > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > > where Uros's __percpu checks kick in.
> > > > >
> > > > > Great. Thanks for checking and quick fix.
> > > > >
> > > > > btw clang supports it with __attribute__((address_space(256))),
> > > > > so CC_IS_GCC probably should be relaxed.
> > > >
> > > > https://github.com/llvm/llvm-project/issues/93449
> > > >
> > > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > > (preferably by someone having a deep knowledge of clang) before it is
> > > > enabled by default.
> > >
> > > clang error makes sense to me.
> >
> > It is not an error, but an internal compiler error. This should never happen.
>
> Not quite. llvm backends don't have a good way to explain the error,
> but this is invalid condition.
> Arguably llvm should do a better job in such cases instead of
> printing stack trace.
>
> >
> > > What does it even mean to do addr space cast from percpu to normal address:
> > >
> > > __typeof__(int __seg_gs) const_pcpu_hot;
> > > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> > >     (void *)(long)&const_pcpu_hot;
> >
> > Please see [1] for an explanation.
> >
> > [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces
>
> You didn't answer my question.

Actually, the above link explains and documents the issue:

"... these address spaces are not considered to be subspaces of the
generic (flat) address space. This means that explicit casts are
required to convert pointers between these address spaces and the
generic address space. In practice the application should cast to
uintptr_t and apply the segment base offset that it installed
previously."

IOW, for __seg_gs address space, there exists no (known) offset that
would define it as a subspace of the generic space. It is gs: prefix
that results in segment override that "switches" to __seg_gs address
space. So, to convert the pointer from __seg_gs to (nonsensical!)
generic address space, GCC allows explicit (void *)(uintptr_t) cast
that in effect just strips gs: prefix from the address. You can then
use the pointer as a pointer to a generic space, but you can't use it
to dereference data from __seg_gs address space - this would be
nonsensical, so (__seg_gs void *)(uintptr_t) cast is needed to convert
pointer back to __seg_gs AS.

> As suspected, gcc is producing garbage code.

Nope, this is expected and well documented behavior.

> See:
> https://godbolt.org/z/ozozYY3nv
>
> For
> void *ptr = (void *)(long)&pcpu_hot;
>
> gcc emits
> .quad pcpu_hot
> which is nonsensical, while clang refuses to produce garbage
> and dumps stack.
>
> Sadly, both compilers produce garbage for ret_addr()

No, they are correct. The pointer is explicitly cast to generic
address space and this is what you get.

> and both compilers produce correct code for ret_value().
> At least something.
>
> Uros,
> your percpu code is broken.
> you shouldn't rely on gcc producing garbage.
> Sooner or later gcc will start erroring on it just as clang.

It won't. It is well documented behavior, as documented in [1].
Regarding linux code, you "should not" pass a pointer to generic
address space to dereference percpu data. Currently,
__verify_percpu_ptr() only triggers a warning when sparse checking is
used, but my patchset will now enforce this as a compile-time error
(this was a much sought feature, and it was possible to implement only
recently by using the newly introduced typeof_unqual() operator). Rest
assured, before enabling this feature in linux, plenty of people
unsuccessfully tried to poke a hole in this functionality and long
threads are archived where address space functionality was discussed
to death. ;)

BTW: You can use:

--cut here--
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 474d648bca9a..e6a7525c9db9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -105,6 +105,10 @@
 # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
 # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
 # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
+
+# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
+#  define __percpu_qual        __attribute__((address_space(3)))
+# endif
 #endif

 #define __percpu_arg(x)        __percpu_prefix "%" #x
--cut here--

to also see clang's address space checks in action on x86 even without
working __seg_gs support (You will need to disable
Wduplicate-decl-specifier warning).

HTH,
Uros.

Re: linux-next: build failure after merge of the bpf-next tree

[Alexei Starovoitov]

On Thu, Mar 20, 2025 at 12:49 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Thu, Mar 20, 2025 at 12:17 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Wed, Mar 19, 2025 at 12:44 PM Uros Bizjak <ubizjak@gmail.com> wrote:
> > >
> > > On Wed, Mar 19, 2025 at 7:56 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Mar 19, 2025 at 9:06 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > > >
> > > > > On Wed, Mar 19, 2025 at 3:55 PM Alexei Starovoitov
> > > > > <alexei.starovoitov@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Mar 19, 2025 at 7:36 AM Kumar Kartikeya Dwivedi
> > > > > > <memxor@gmail.com> wrote:
> > > > > > >
> > > > > > > > >
> > > > > > > > > I've sent a fix [0], but unfortunately I was unable to reproduce the
> > > > > > > > > problem with an LLVM >= 19 build, idk why. I will try with GCC >= 14
> > > > > > > > > as the patches require to confirm, but based on the error I am 99%
> > > > > > > > > sure it will fix the problem.
> > > > > > > >
> > > > > > > > Probably because __seg_gs has CC_HAS_NAMED_AS depends on CC_IS_GCC.
> > > > > > > > Let me give it a go with GCC.
> > > > > > > >
> > > > > > >
> > > > > > > Can confirm now that this fixes it, I just did a build with GCC 14
> > > > > > > where Uros's __percpu checks kick in.
> > > > > >
> > > > > > Great. Thanks for checking and quick fix.
> > > > > >
> > > > > > btw clang supports it with __attribute__((address_space(256))),
> > > > > > so CC_IS_GCC probably should be relaxed.
> > > > >
> > > > > https://github.com/llvm/llvm-project/issues/93449
> > > > >
> > > > > needs to be fixed first. Also, the feature has to be thoroughly tested
> > > > > (preferably by someone having a deep knowledge of clang) before it is
> > > > > enabled by default.
> > > >
> > > > clang error makes sense to me.
> > >
> > > It is not an error, but an internal compiler error. This should never happen.
> >
> > Not quite. llvm backends don't have a good way to explain the error,
> > but this is invalid condition.
> > Arguably llvm should do a better job in such cases instead of
> > printing stack trace.
> >
> > >
> > > > What does it even mean to do addr space cast from percpu to normal address:
> > > >
> > > > __typeof__(int __seg_gs) const_pcpu_hot;
> > > > void *__attribute____UNIQUE_ID___addressable_const_pcpu_hot612 =
> > > >     (void *)(long)&const_pcpu_hot;
> > >
> > > Please see [1] for an explanation.
> > >
> > > [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#x86-Named-Address-Spaces
> >
> > You didn't answer my question.
>
> Actually, the above link explains and documents the issue:
>
> "... these address spaces are not considered to be subspaces of the
> generic (flat) address space. This means that explicit casts are
> required to convert pointers between these address spaces and the
> generic address space. In practice the application should cast to
> uintptr_t and apply the segment base offset that it installed
> previously."
>
> IOW, for __seg_gs address space, there exists no (known) offset that
> would define it as a subspace of the generic space. It is gs: prefix
> that results in segment override that "switches" to __seg_gs address
> space. So, to convert the pointer from __seg_gs to (nonsensical!)
> generic address space, GCC allows explicit (void *)(uintptr_t) cast
> that in effect just strips gs: prefix from the address. You can then
> use the pointer as a pointer to a generic space, but you can't use it
> to dereference data from __seg_gs address space - this would be
> nonsensical, so (__seg_gs void *)(uintptr_t) cast is needed to convert
> pointer back to __seg_gs AS.

tbh, I don't see how the above doc sentence means "just strip gs:".
But ok, if that's what gcc folks clarified as true intent and it's
not going to change.
btw both compilers disallow automatic variables with address space
qualifier and that makes sense, but if "just strip gs:" would be
the rule then auto var with gs should have meant "just strip" too.
Weird.

> > As suspected, gcc is producing garbage code.
>
> Nope, this is expected and well documented behavior.
>
> > See:
> > https://godbolt.org/z/ozozYY3nv
> >
> > For
> > void *ptr = (void *)(long)&pcpu_hot;
> >
> > gcc emits
> > .quad pcpu_hot
> > which is nonsensical, while clang refuses to produce garbage
> > and dumps stack.
> >
> > Sadly, both compilers produce garbage for ret_addr()
>
> No, they are correct. The pointer is explicitly cast to generic
> address space and this is what you get.
>
> > and both compilers produce correct code for ret_value().
> > At least something.
> >
> > Uros,
> > your percpu code is broken.
> > you shouldn't rely on gcc producing garbage.
> > Sooner or later gcc will start erroring on it just as clang.
>
> It won't. It is well documented behavior, as documented in [1].
> Regarding linux code, you "should not" pass a pointer to generic
> address space to dereference percpu data. Currently,
> __verify_percpu_ptr() only triggers a warning when sparse checking is
> used, but my patchset will now enforce this as a compile-time error
> (this was a much sought feature, and it was possible to implement only
> recently by using the newly introduced typeof_unqual() operator).

That value proposition of the patch is clear. It's a good check,
no doubt. My point that compilers could have done it just fine
without using this "just strip gs:" rule for global percpu variables.
I suspect it should be possible to craft the macro
without assigning (void *)(long)&pcpu_hot into global var.
And both compilers would have worked.

> Rest
> assured, before enabling this feature in linux, plenty of people
> unsuccessfully tried to poke a hole in this functionality and long
> threads are archived where address space functionality was discussed
> to death. ;)
>
> BTW: You can use:
>
> --cut here--
> diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> index 474d648bca9a..e6a7525c9db9 100644
> --- a/arch/x86/include/asm/percpu.h
> +++ b/arch/x86/include/asm/percpu.h
> @@ -105,6 +105,10 @@
>  # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
>  # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
>  # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
> +
> +# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
> +#  define __percpu_qual        __attribute__((address_space(3)))

I see, so for undefined addr spaces clang x86 just ignores it.
Weird. But ok.

Re: linux-next: build failure after merge of the bpf-next tree

[Uros Bizjak]

On Fri, Mar 21, 2025 at 12:18 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:

> > BTW: You can use:
> >
> > --cut here--
> > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
> > index 474d648bca9a..e6a7525c9db9 100644
> > --- a/arch/x86/include/asm/percpu.h
> > +++ b/arch/x86/include/asm/percpu.h
> > @@ -105,6 +105,10 @@
> >  # define __my_cpu_type(var)    typeof(var) __percpu_seg_override
> >  # define __my_cpu_ptr(ptr)    (__my_cpu_type(*(ptr))*)(__force uintptr_t)(ptr)
> >  # define __my_cpu_var(var)    (*__my_cpu_ptr(&(var)))
> > +
> > +# if __has_attribute(address_space) && defined(USE_TYPEOF_UNQUAL)
> > +#  define __percpu_qual        __attribute__((address_space(3)))
>
> I see, so for undefined addr spaces clang x86 just ignores it.
> Weird. But ok.

It ignores undefined addr spaces in the sense that it does nothing
with it. It has no effect on the access to variables in this addr
space. OTOH, the compiler still applies address space checks. I plan
to propose a (RFC?) patch after rc1, once the main part is applied to
the mainline, that enables percpu checks also for clang. It is in
effect just the above couple of lines.

Uros.

linux-next: build failure after merge of the bpf-next tree

[Thierry Reding]

Hi all,

After merging the bpf-next tree, today's linux-next build (x86_64_perf)
failed like this:

      CC      builtin-trace.o
    builtin-trace.c: In function ‘syscall_arg__strtoul_btf_enum’:
    builtin-trace.c:972:27: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
      972 |         for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
          |                           ^
      CC      util/btf.o
    util/btf.c: In function ‘__btf_type__find_member_by_name’:
    util/btf.c:19:43: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
       19 |         for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
          |                                           ^

Caused by commit

    f7a6b9eaff3e ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")

I've fixed it up like below, but please fix this in your tree as well.

Thanks,
Thierry

--- >8 ---
From 4689669414ed7de19a69803714bc04e96fd82618 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Mon, 27 Apr 2026 12:32:06 +0200
Subject: [PATCH] perf: Fixup for btf_vlan() API change

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 tools/perf/builtin-trace.c | 2 +-
 tools/perf/util/btf.c      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index e58c49d047a2..d22e20a57b70 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -969,7 +969,7 @@ static bool syscall_arg__strtoul_btf_enum(char *bf, size_t size, struct syscall_
 	struct btf *btf = arg->trace->btf;
 	struct btf_enum *be = btf_enum(bt);
 
-	for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
+	for (u32 i = 0; i < btf_vlen(bt); ++i, ++be) {
 		const char *name = btf__name_by_offset(btf, be->name_off);
 		int max_len = max(size, strlen(name));
 
diff --git a/tools/perf/util/btf.c b/tools/perf/util/btf.c
index bb163fe87767..50d98f3e83bf 100644
--- a/tools/perf/util/btf.c
+++ b/tools/perf/util/btf.c
@@ -14,7 +14,7 @@ const struct btf_member *__btf_type__find_member_by_name(struct btf *btf,
 {
 	const struct btf_type *t = btf__type_by_id(btf, type_id);
 	const struct btf_member *m;
-	int i;
+	u32 i;
 
 	for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
 		const char *current_member_name = btf__name_by_offset(btf, m->name_off);
-- 
2.52.0
--- >8 ---

Re: linux-next: build failure after merge of the bpf-next tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Mon, Apr 27, 2026 at 03:26:01PM +0200, Thierry Reding wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (x86_64_perf)
> failed like this:
> 
>       CC      builtin-trace.o
>     builtin-trace.c: In function ‘syscall_arg__strtoul_btf_enum’:
>     builtin-trace.c:972:27: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
>       972 |         for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
>           |                           ^
>       CC      util/btf.o
>     util/btf.c: In function ‘__btf_type__find_member_by_name’:
>     util/btf.c:19:43: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
>        19 |         for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
>           |                                           ^
> 
> Caused by commit
> 
>     f7a6b9eaff3e ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")
> 
> I've fixed it up like below, but please fix this in your tree as well.

Given that I later saw that the build broke due to the other change and
I had to use the old bpf-next tree, this fixup is no longer in the tree
but it should still be fixed so that bpf-next can be merged into linux-
next again soon.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: build failure after merge of the bpf-next tree

[Alan Maguire]

On 27/04/2026 14:26, Thierry Reding wrote:
> Hi all,
> 
> After merging the bpf-next tree, today's linux-next build (x86_64_perf)
> failed like this:
> 
>       CC      builtin-trace.o
>     builtin-trace.c: In function ‘syscall_arg__strtoul_btf_enum’:
>     builtin-trace.c:972:27: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
>       972 |         for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
>           |                           ^
>       CC      util/btf.o
>     util/btf.c: In function ‘__btf_type__find_member_by_name’:
>     util/btf.c:19:43: error: comparison of integer expressions of different signedness: ‘int’ and ‘__u32’ {aka ‘unsigned int’} [-Werror=sign-compare]
>        19 |         for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
>           |                                           ^
> 
> Caused by commit
> 
>     f7a6b9eaff3e ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")
> 
> I've fixed it up like below, but please fix this in your tree as well.
> 
> Thanks,
> Thierry
> 
> --- >8 ---
> From 4689669414ed7de19a69803714bc04e96fd82618 Mon Sep 17 00:00:00 2001
> From: Thierry Reding <treding@nvidia.com>
> Date: Mon, 27 Apr 2026 12:32:06 +0200
> Subject: [PATCH] perf: Fixup for btf_vlan() API change
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>

Reviewed-by: Alan Maguire <alan.maguire@oracle.com>

Thanks for the fix!

> ---
>  tools/perf/builtin-trace.c | 2 +-
>  tools/perf/util/btf.c      | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index e58c49d047a2..d22e20a57b70 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -969,7 +969,7 @@ static bool syscall_arg__strtoul_btf_enum(char *bf, size_t size, struct syscall_
>  	struct btf *btf = arg->trace->btf;
>  	struct btf_enum *be = btf_enum(bt);
>  
> -	for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
> +	for (u32 i = 0; i < btf_vlen(bt); ++i, ++be) {
>  		const char *name = btf__name_by_offset(btf, be->name_off);
>  		int max_len = max(size, strlen(name));
>  
> diff --git a/tools/perf/util/btf.c b/tools/perf/util/btf.c
> index bb163fe87767..50d98f3e83bf 100644
> --- a/tools/perf/util/btf.c
> +++ b/tools/perf/util/btf.c
> @@ -14,7 +14,7 @@ const struct btf_member *__btf_type__find_member_by_name(struct btf *btf,
>  {
>  	const struct btf_type *t = btf__type_by_id(btf, type_id);
>  	const struct btf_member *m;
> -	int i;
> +	u32 i;
>  
>  	for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
>  		const char *current_member_name = btf__name_by_offset(btf, m->name_off);

Re: linux-next: build failure after merge of the bpf-next tree

[sashiko-bot]

Sashiko AI review found 1 potential issue(s):
- [Low] Incomplete adaptation to the btf_vlen() return type change.
--

commit 0212f8f14ef9fb92c19bf796baf0b7ea6478e094
Author: Thierry Reding <thierry.reding@kernel.org>

linux-next: build failure after merge of the bpf-next tree

After merging the bpf-next tree, today's linux-next build (x86_64_perf)
failed due to a sign-compare error. This patch fixes the build by changing
loop variables to match the unsigned return type of btf_vlen().

> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index e58c49d047a2..d22e20a57b70 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -969,7 +969,7 @@ static bool syscall_arg__strtoul_btf_enum(char *bf, size_t size, struct syscall_
>  	struct btf *btf = arg->trace->btf;
>  	struct btf_enum *be = btf_enum(bt);
>  
> -	for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
> +	for (u32 i = 0; i < btf_vlen(bt); ++i, ++be) {
>  		const char *name = btf__name_by_offset(btf, be->name_off);
>  		int max_len = max(size, strlen(name));

Should btf_enum_scnprintf() in the same file also be updated for
consistency?

It appears the unsigned return value of btf_vlen() is implicitly cast to int
there, masking the sign-compare warning:

tools/perf/builtin-trace.c:btf_enum_scnprintf() {
    ...
	const int nr_entries = btf_vlen(type);

	for (int i = 0; i < nr_entries; ++i, ++be) {
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260427132604.3754048-1-thierry.reding@kernel.org?part=1