xfrm regression in 5.10.94

xfrm regression in 5.10.94

[Kai Lüke]

Hi,

in 5.10.94 these two xfrm changes cause userspace programs like Cilium to
suddenly fail (https://github.com/cilium/cilium/pull/18789):
- xfrm: interface with if_id 0 should return error
  8dce43919566f06e865f7e8949f5c10d8c2493f5
- xfrm: state and policy should fail if XFRMA_IF_ID 0
  68ac0f3810e76a853b5f7b90601a05c3048b8b54

I see that these changes are a reaction to
- xfrm: fix disable_xfrm sysctl when used on xfrm interfaces
  9f8550e4bd9d
but even if the "wrong" usage caused weird behavior I still wonder if it
was the right decision to do the changes as part of a bugfix update for an
LTS kernel.
What do you think about reverting the changes at least for 5.10?

Regards,
Kai

Re: xfrm regression in 5.10.94

[Greg KH]

On Mon, Feb 28, 2022 at 01:22:09PM +0100, Kai Lüke wrote:
> Hi,
> 
> in 5.10.94 these two xfrm changes cause userspace programs like Cilium to
> suddenly fail (https://github.com/cilium/cilium/pull/18789):
> - xfrm: interface with if_id 0 should return error
>   8dce43919566f06e865f7e8949f5c10d8c2493f5
> - xfrm: state and policy should fail if XFRMA_IF_ID 0
>   68ac0f3810e76a853b5f7b90601a05c3048b8b54
> 
> I see that these changes are a reaction to
> - xfrm: fix disable_xfrm sysctl when used on xfrm interfaces
>   9f8550e4bd9d
> but even if the "wrong" usage caused weird behavior I still wonder if it
> was the right decision to do the changes as part of a bugfix update for an
> LTS kernel.
> What do you think about reverting the changes at least for 5.10?

Why is 5.10 special and newer kernels are not?  This change shows up for
them, right?  Either this is a regression for all kernel releases and
needs to be resolved, or it is ok for any kernel release.

Please work with the networking developers to either resolve the
regression of determine what needs to be done here for userspace to work
properly.

thanks,

greg k-h

Re: xfrm regression in 5.10.94

[Kai Lueke]

Hi,
> Why is 5.10 special and newer kernels are not?  This change shows up for
> them, right?  Either this is a regression for all kernel releases and
> needs to be resolved, or it is ok for any kernel release.
>
> Please work with the networking developers to either resolve the
> regression of determine what needs to be done here for userspace to work
> properly.

I agree, thanks. I tried it
(https://marc.info/?t=164607426900002&r=1&w=2) and got this response
from Steffen Klassert now:

> In general I agree that the userspace ABI has to be stable, but
> this never worked. We changed the behaviour from silently broken to
> notify userspace about a misconfiguration.
>
> It is the question what is more annoying for the users. A bug that
> we can never fix, or changing a broken behaviour to something that
> tells you at least why it is not working.
>
> In such a case we should gauge what's the better solution. Here
> I tend to keep it as it is.
(https://marc.info/?l=linux-netdev&m=164615098503579&w=2)

Given it's unlikely to have this reverted in general I personally think
that reverting for the LTS kernels makes sense at least...

Regards,
Kai

Re: xfrm regression in 5.10.94

[Greg KH]

On Tue, Mar 01, 2022 at 05:34:00PM +0100, Kai Lueke wrote:
> Hi,
> > Why is 5.10 special and newer kernels are not?  This change shows up for
> > them, right?  Either this is a regression for all kernel releases and
> > needs to be resolved, or it is ok for any kernel release.
> >
> > Please work with the networking developers to either resolve the
> > regression of determine what needs to be done here for userspace to work
> > properly.
> 
> I agree, thanks. I tried it
> (https://marc.info/?t=164607426900002&r=1&w=2) and got this response
> from Steffen Klassert now:
> 
> > In general I agree that the userspace ABI has to be stable, but
> > this never worked. We changed the behaviour from silently broken to
> > notify userspace about a misconfiguration.
> >
> > It is the question what is more annoying for the users. A bug that
> > we can never fix, or changing a broken behaviour to something that
> > tells you at least why it is not working.
> >
> > In such a case we should gauge what's the better solution. Here
> > I tend to keep it as it is.
> (https://marc.info/?l=linux-netdev&m=164615098503579&w=2)
> 
> Given it's unlikely to have this reverted in general I personally think
> that reverting for the LTS kernels makes sense at least...

Again, there is nothing "special" about LTS kernels for stuff like this.
It's fixing a bug that the kernel developers wanted to have fixed, and
so it gets backported everywhere relevant.

If I were to somehow "wait" on taking this, it's only delaying your
fixes from ever happening :)

thanks,

greg k-h