strace build error static assertion failed: "XFRM_MSG_MAPPING != 0x26"

Hi,

When compiling strace-5.14 (although it looks like the same problem 
would exist with bleeding edge strace) with headers from the tip of 
Linus's tree (5.15.0-rc4) I get the following error

strace: In file included from static_assert.h:11,
strace:                  from print_fields.h:12,
strace:                  from defs.h:1901,
strace:                  from netlink.c:10:
strace: xlat/nl_xfrm_types.h:162:1: error: static assertion failed: 
"XFRM_MSG_MAPPING != 0x26"
strace:  static_assert((XFRM_MSG_MAPPING) == (0x26), "XFRM_MSG_MAPPING 
!= 0x26");
strace:  ^~~~~~~~~~~~~

It looks like commit 2d151d39073a ("xfrm: Add possibility to set the 
default to block if we have no policy") added some XFRM messages and the 
numbers shifted. Is this considered an ABI breakage?

I'm not sure if this is a strace problem or a linux problem so I'm 
reporting it in both places.

Thanks,
Chris

On Wed, Oct 06, 2021 at 09:43:11PM +0000, Chris Packham wrote:

Hi,

When compiling strace-5.14 (although it looks like the same problem 
would exist with bleeding edge strace) with headers from the tip of 
Linus's tree (5.15.0-rc4) I get the following error

strace: In file included from static_assert.h:11,
strace:                  from print_fields.h:12,
strace:                  from defs.h:1901,
strace:                  from netlink.c:10:
strace: xlat/nl_xfrm_types.h:162:1: error: static assertion failed: 
"XFRM_MSG_MAPPING != 0x26"
strace:  static_assert((XFRM_MSG_MAPPING) == (0x26), "XFRM_MSG_MAPPING 
!= 0x26");
strace:  ^~~~~~~~~~~~~

It looks like commit 2d151d39073a ("xfrm: Add possibility to set the 
default to block if we have no policy") added some XFRM messages and the 
numbers shifted. Is this considered an ABI breakage?

I'm not sure if this is a strace problem or a linux problem so I'm 
reporting it in both places.

Yes, this is already covered by 
https://lore.kernel.org/lkml/20210912122234.GA22469@asgard.redhat.com/T/#u

Thanks,


-- 
ldv

On Thu, Oct 07, 2021 at 12:48:16AM +0300, Dmitry V. Levin wrote:

On Wed, Oct 06, 2021 at 09:43:11PM +0000, Chris Packham wrote:

quoted

Hi,

When compiling strace-5.14 (although it looks like the same problem 
would exist with bleeding edge strace) with headers from the tip of 
Linus's tree (5.15.0-rc4) I get the following error

strace: In file included from static_assert.h:11,
strace:                  from print_fields.h:12,
strace:                  from defs.h:1901,
strace:                  from netlink.c:10:
strace: xlat/nl_xfrm_types.h:162:1: error: static assertion failed: 
"XFRM_MSG_MAPPING != 0x26"
strace:  static_assert((XFRM_MSG_MAPPING) == (0x26), "XFRM_MSG_MAPPING 
!= 0x26");
strace:  ^~~~~~~~~~~~~

It looks like commit 2d151d39073a ("xfrm: Add possibility to set the 
default to block if we have no policy") added some XFRM messages and the 
numbers shifted. Is this considered an ABI breakage?

I'm not sure if this is a strace problem or a linux problem so I'm 
reporting it in both places.

Yes, this is already covered by 
https://lore.kernel.org/lkml/20210912122234.GA22469@asgard.redhat.com/T/#u

Thanks,

I wonder, why the fix hasn't been merged yet, though.


-- 
ldv

On Thu, Oct 07, 2021 at 12:51:24AM +0300, Dmitry V. Levin wrote:

On Thu, Oct 07, 2021 at 12:48:16AM +0300, Dmitry V. Levin wrote:

quoted

On Wed, Oct 06, 2021 at 09:43:11PM +0000, Chris Packham wrote:

quoted

Hi,

When compiling strace-5.14 (although it looks like the same problem 
would exist with bleeding edge strace) with headers from the tip of 
Linus's tree (5.15.0-rc4) I get the following error

strace: In file included from static_assert.h:11,
strace:                  from print_fields.h:12,
strace:                  from defs.h:1901,
strace:                  from netlink.c:10:
strace: xlat/nl_xfrm_types.h:162:1: error: static assertion failed: 
"XFRM_MSG_MAPPING != 0x26"
strace:  static_assert((XFRM_MSG_MAPPING) == (0x26), "XFRM_MSG_MAPPING 
!= 0x26");
strace:  ^~~~~~~~~~~~~

It looks like commit 2d151d39073a ("xfrm: Add possibility to set the 
default to block if we have no policy") added some XFRM messages and the 
numbers shifted. Is this considered an ABI breakage?

I'm not sure if this is a strace problem or a linux problem so I'm 
reporting it in both places.

Yes, this is already covered by 
https://lore.kernel.org/lkml/20210912122234.GA22469@asgard.redhat.com/T/#u

Thanks,

I wonder, why the fix hasn't been merged yet, though.

That was due to a delay on my side. I've just sent a pull request
with the fix included.