summaryrefslogtreecommitdiff
path: root/include/uapi/linux/securebits.h
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2026-09-12 13:24:01 -0700
committerJakub Kicinski <kuba@kernel.org>2026-09-15 16:49:32 -0700
commitb785f5c56fb3dbe70635592b11547a2c828e95b3 (patch)
tree02ce0f22b84f186464ed86413ac63e2739bc9206 /include/uapi/linux/securebits.h
parent032ef43b9dab22f1e2fe9923b4d8b23d3ea9943d (diff)
downloadlinux-next-b785f5c56fb3dbe70635592b11547a2c828e95b3.tar.gz
linux-next-b785f5c56fb3dbe70635592b11547a2c828e95b3.zip
netlink: policy: report the big endian attributes
Paolo pointed out an issue flagged at low priority by Sashiko - we're currently not handling BE{16,32} attributes in policy dumps. Commit 3f4285d741b4 ("netlink: specs: fou: local-v4 and peer-v4 are big endian") flipped two fou attributes from NLA_U32 to NLA_BE32. This made them vanish from the policy dump. Follow the YAML spec format and treat byte order as a property of a u16 / u32 rather than a type of its own. I don't have a strong preference either way. The YNL format "feels cleaner" but the kernel's separate type is easier when handling decoding. I don't think that the policy type is actually usable for decoding (since it only contains input types) so I went with YNL and added the separate attr. A missing byte order means host order, again like in the YAML specs. Link: https://lore.kernel.org/ab90f970-0ebb-4c07-b7b1-db3f91395116@redhat.com Link: https://patch.msgid.link/20260912202401.141336-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include/uapi/linux/securebits.h')
0 files changed, 0 insertions, 0 deletions