All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] netlink: add variable-length / auto integers
@ 2023-10-11  0:33 Jakub Kicinski
  2023-10-11  3:20 ` kernel test robot
                   ` (4 more replies)
  0 siblings, 5 replies; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11  0:33 UTC (permalink / raw)
  To: netdev
  Cc: nicolas.dichtel, johannes, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Jakub Kicinski

We currently push everyone to use padding to align 64b values in netlink.
I'm not sure what the story behind this is. I found this:
https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t
but it doesn't go into details WRT the motivation.
Even for arches which don't have good unaligned access - I'd think
that access aligned to 4B *is* pretty efficient, and that's all
we need. Plus kernel deals with unaligned input. Why can't user space?

Padded 64b is quite space-inefficient (64b + pad means at worst 16B
per attr vs 32b which takes 8B). It is also more typing:

    if (nla_put_u64_pad(rsp, NETDEV_A_SOMETHING_SOMETHING,
                        value, NETDEV_A_SOMETHING_PAD))

Create a new attribute type which will use 32 bits at netlink
level if value is small enough (probably most of the time?),
and (4B-aligned) 64 bits otherwise. Kernel API is just:

    if (nla_put_uint(rsp, NETDEV_A_SOMETHING_SOMETHING, value))

Calling this new type "just" sint / uint with no specific size
will hopefully also make people more comfortable with using it.
Currently telling people "don't use u8, you may need the space,
and netlink will round up to 4B, anyway" is the #1 comment
we give to newcomers.

In terms of netlink layout it looks like this:

         0       4       8       12      16
32b:     [nlattr][ u32  ]
64b:     [  pad ][nlattr][     u64      ]
uint(32) [nlattr][ u32  ]
uint(64) [nlattr][     u64      ]

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Thoughts?

This is completely untested. YNL to follow.
---
 include/net/netlink.h        | 62 ++++++++++++++++++++++++++++++++++--
 include/uapi/linux/netlink.h |  5 +++
 lib/nlattr.c                 |  9 ++++++
 net/netlink/policy.c         | 14 ++++++--
 4 files changed, 85 insertions(+), 5 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index 8a7cd1170e1f..523486dfe4f3 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -183,6 +183,8 @@ enum {
 	NLA_REJECT,
 	NLA_BE16,
 	NLA_BE32,
+	NLA_SINT,
+	NLA_UINT,
 	__NLA_TYPE_MAX,
 };
 
@@ -377,9 +379,11 @@ struct nla_policy {
 
 #define __NLA_IS_UINT_TYPE(tp)					\
 	(tp == NLA_U8 || tp == NLA_U16 || tp == NLA_U32 ||	\
-	 tp == NLA_U64 || tp == NLA_BE16 || tp == NLA_BE32)
+	 tp == NLA_U64 || tp == NLA_UINT ||			\
+	 tp == NLA_BE16 || tp == NLA_BE32)
 #define __NLA_IS_SINT_TYPE(tp)						\
-	(tp == NLA_S8 || tp == NLA_S16 || tp == NLA_S32 || tp == NLA_S64)
+	(tp == NLA_S8 || tp == NLA_S16 || tp == NLA_S32 || tp == NLA_S64 || \
+	 tp == NLA_SINT)
 
 #define __NLA_ENSURE(condition) BUILD_BUG_ON_ZERO(!(condition))
 #define NLA_ENSURE_UINT_TYPE(tp)			\
@@ -1357,6 +1361,22 @@ static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
 	return nla_put(skb, attrtype, sizeof(u32), &tmp);
 }
 
+/**
+ * nla_put_uint - Add a variable-size unsigned int to a socket buffer
+ * @skb: socket buffer to add attribute to
+ * @attrtype: attribute type
+ * @value: numeric value
+ */
+static inline int nla_put_uint(struct sk_buff *skb, int attrtype, u64 value)
+{
+	u64 tmp64 = value;
+	u32 tmp32 = value;
+
+	if (tmp64 == tmp32)
+		return nla_put_u32(skb, attrtype, tmp32);
+	return nla_put(skb, attrtype, sizeof(u64), &tmp64);
+}
+
 /**
  * nla_put_be32 - Add a __be32 netlink attribute to a socket buffer
  * @skb: socket buffer to add attribute to
@@ -1511,6 +1531,22 @@ static inline int nla_put_s64(struct sk_buff *skb, int attrtype, s64 value,
 	return nla_put_64bit(skb, attrtype, sizeof(s64), &tmp, padattr);
 }
 
+/**
+ * nla_put_sint - Add a variable-size signed int to a socket buffer
+ * @skb: socket buffer to add attribute to
+ * @attrtype: attribute type
+ * @value: numeric value
+ */
+static inline int nla_put_sint(struct sk_buff *skb, int attrtype, s64 value)
+{
+	s64 tmp64 = value;
+	s32 tmp32 = value;
+
+	if (tmp64 == tmp32)
+		return nla_put_s32(skb, attrtype, tmp32);
+	return nla_put(skb, attrtype, sizeof(s64), &tmp64);
+}
+
 /**
  * nla_put_string - Add a string netlink attribute to a socket buffer
  * @skb: socket buffer to add attribute to
@@ -1600,6 +1636,17 @@ static inline u32 nla_get_u32(const struct nlattr *nla)
 	return *(u32 *) nla_data(nla);
 }
 
+/**
+ * nla_get_uint - return payload of uint attribute
+ * @nla: uint netlink attribute
+ */
+static inline u64 nla_get_uint(const struct nlattr *nla)
+{
+	if (nla_len(nla) == sizeof(u32))
+		return nla_get_u32(nla);
+	return nla_get_u64(nla);
+}
+
 /**
  * nla_get_be32 - return payload of __be32 attribute
  * @nla: __be32 netlink attribute
@@ -1729,6 +1776,17 @@ static inline s64 nla_get_s64(const struct nlattr *nla)
 	return tmp;
 }
 
+/**
+ * nla_get_sint - return payload of uint attribute
+ * @nla: uint netlink attribute
+ */
+static inline s64 nla_get_sint(const struct nlattr *nla)
+{
+	if (nla_len(nla) == sizeof(s32))
+		return nla_get_s32(nla);
+	return nla_get_s64(nla);
+}
+
 /**
  * nla_get_flag - return payload of flag attribute
  * @nla: flag netlink attribute
diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index e2ae82e3f9f7..f87aaf28a649 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -298,6 +298,8 @@ struct nla_bitfield32 {
  *	entry has attributes again, the policy for those inner ones
  *	and the corresponding maxtype may be specified.
  * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
+ * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
+ * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B
  */
 enum netlink_attribute_type {
 	NL_ATTR_TYPE_INVALID,
@@ -322,6 +324,9 @@ enum netlink_attribute_type {
 	NL_ATTR_TYPE_NESTED_ARRAY,
 
 	NL_ATTR_TYPE_BITFIELD32,
+
+	NL_ATTR_TYPE_SINT,
+	NL_ATTR_TYPE_UINT,
 };
 
 /**
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 7a2b6c38fd59..116459f35a4c 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -433,6 +433,15 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
 			goto out_err;
 		break;
 
+	case NLA_SINT:
+	case NLA_UINT:
+		if (attrlen != sizeof(u32) && attrlen != sizeof(u64)) {
+			NL_SET_ERR_MSG_ATTR_POL(extack, nla, pt,
+						"invalid attribute length");
+			return -EINVAL;
+		}
+		break;
+
 	case NLA_BITFIELD32:
 		if (attrlen != sizeof(struct nla_bitfield32))
 			goto out_err;
diff --git a/net/netlink/policy.c b/net/netlink/policy.c
index e2f111edf66c..1f8909c16f14 100644
--- a/net/netlink/policy.c
+++ b/net/netlink/policy.c
@@ -230,6 +230,8 @@ int netlink_policy_dump_attr_size_estimate(const struct nla_policy *pt)
 	case NLA_S16:
 	case NLA_S32:
 	case NLA_S64:
+	case NLA_SINT:
+	case NLA_UINT:
 		/* maximum is common, u64 min/max with padding */
 		return common +
 		       2 * (nla_attr_size(0) + nla_attr_size(sizeof(u64)));
@@ -288,6 +290,7 @@ __netlink_policy_dump_write_attr(struct netlink_policy_dump_state *state,
 	case NLA_U16:
 	case NLA_U32:
 	case NLA_U64:
+	case NLA_UINT:
 	case NLA_MSECS: {
 		struct netlink_range_validation range;
 
@@ -297,8 +300,10 @@ __netlink_policy_dump_write_attr(struct netlink_policy_dump_state *state,
 			type = NL_ATTR_TYPE_U16;
 		else if (pt->type == NLA_U32)
 			type = NL_ATTR_TYPE_U32;
-		else
+		else if (pt->type == NLA_U64)
 			type = NL_ATTR_TYPE_U64;
+		else
+			type = NL_ATTR_TYPE_UINT;
 
 		if (pt->validation_type == NLA_VALIDATE_MASK) {
 			if (nla_put_u64_64bit(skb, NL_POLICY_TYPE_ATTR_MASK,
@@ -320,7 +325,8 @@ __netlink_policy_dump_write_attr(struct netlink_policy_dump_state *state,
 	case NLA_S8:
 	case NLA_S16:
 	case NLA_S32:
-	case NLA_S64: {
+	case NLA_S64:
+	case NLA_SINT: {
 		struct netlink_range_validation_signed range;
 
 		if (pt->type == NLA_S8)
@@ -329,8 +335,10 @@ __netlink_policy_dump_write_attr(struct netlink_policy_dump_state *state,
 			type = NL_ATTR_TYPE_S16;
 		else if (pt->type == NLA_S32)
 			type = NL_ATTR_TYPE_S32;
-		else
+		else if (pt->type == NLA_S64)
 			type = NL_ATTR_TYPE_S64;
+		else
+			type = NL_ATTR_TYPE_SINT;
 
 		nla_get_range_signed(pt, &range);
 
-- 
2.41.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
@ 2023-10-11  3:20 ` kernel test robot
  2023-10-11 13:11 ` Johannes Berg
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 21+ messages in thread
From: kernel test robot @ 2023-10-11  3:20 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: oe-kbuild-all

Hi Jakub,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on net/main]
[also build test ERROR on net-next/main linus/master v6.6-rc5 next-20231010]
[cannot apply to horms-ipvs/master]
[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/Jakub-Kicinski/netlink-add-variable-length-auto-integers/20231011-083419
base:   net/main
patch link:    https://lore.kernel.org/r/20231011003313.105315-1-kuba%40kernel.org
patch subject: [RFC] netlink: add variable-length / auto integers
config: parisc-allyesconfig (https://download.01.org/0day-ci/archive/20231011/202310111153.GGkzOshH-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231011/202310111153.GGkzOshH-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/202310111153.GGkzOshH-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/net/rtnetlink.h:6,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from lib/kobject_uevent.c:28:
   include/net/netlink.h: In function 'nla_get_uint':
>> include/net/netlink.h:1647:16: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
         |                nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'; have 'u64(const struct nlattr *)' {aka 'long long unsigned int(const struct nlattr *)'}
    1708 | static inline u64 nla_get_u64(const struct nlattr *nla)
         |                   ^~~~~~~~~~~
   include/net/netlink.h:1647:16: note: previous implicit declaration of 'nla_get_u64' with type 'int()'
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from include/linux/tcp.h:19,
                    from include/linux/ipv6.h:94,
                    from include/net/addrconf.h:52,
                    from lib/vsprintf.c:41:
   include/net/netlink.h: In function 'nla_get_uint':
>> include/net/netlink.h:1647:16: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
         |                nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'; have 'u64(const struct nlattr *)' {aka 'long long unsigned int(const struct nlattr *)'}
    1708 | static inline u64 nla_get_u64(const struct nlattr *nla)
         |                   ^~~~~~~~~~~
   include/net/netlink.h:1647:16: note: previous implicit declaration of 'nla_get_u64' with type 'int()'
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
   lib/vsprintf.c: In function 'va_format':
   lib/vsprintf.c:1682:9: warning: function 'va_format' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]
    1682 |         buf += vsnprintf(buf, end > buf ? end - buf : 0, va_fmt->fmt, va);
         |         ^~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from include/net/inet_sock.h:22,
                    from include/linux/udp.h:16,
                    from lib/test_blackhole_dev.c:17:
   include/net/netlink.h: In function 'nla_get_uint':
>> include/net/netlink.h:1647:16: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
         |                nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'; have 'u64(const struct nlattr *)' {aka 'long long unsigned int(const struct nlattr *)'}
    1708 | static inline u64 nla_get_u64(const struct nlattr *nla)
         |                   ^~~~~~~~~~~
   include/net/netlink.h:1647:16: note: previous implicit declaration of 'nla_get_u64' with type 'int()'
    1647 |         return nla_get_u64(nla);
         |                ^~~~~~~~~~~
   lib/test_blackhole_dev.c: In function 'test_blackholedev_init':
   lib/test_blackhole_dev.c:32:24: warning: variable 'ethh' set but not used [-Wunused-but-set-variable]
      32 |         struct ethhdr *ethh;
         |                        ^~~~
   cc1: some warnings being treated as errors


vim +1647 include/net/netlink.h

  1638	
  1639	/**
  1640	 * nla_get_uint - return payload of uint attribute
  1641	 * @nla: uint netlink attribute
  1642	 */
  1643	static inline u64 nla_get_uint(const struct nlattr *nla)
  1644	{
  1645		if (nla_len(nla) == sizeof(u32))
  1646			return nla_get_u32(nla);
> 1647		return nla_get_u64(nla);
  1648	}
  1649	
  1650	/**
  1651	 * nla_get_be32 - return payload of __be32 attribute
  1652	 * @nla: __be32 netlink attribute
  1653	 */
  1654	static inline __be32 nla_get_be32(const struct nlattr *nla)
  1655	{
  1656		return *(__be32 *) nla_data(nla);
  1657	}
  1658	
  1659	/**
  1660	 * nla_get_le32 - return payload of __le32 attribute
  1661	 * @nla: __le32 netlink attribute
  1662	 */
  1663	static inline __le32 nla_get_le32(const struct nlattr *nla)
  1664	{
  1665		return *(__le32 *) nla_data(nla);
  1666	}
  1667	
  1668	/**
  1669	 * nla_get_u16 - return payload of u16 attribute
  1670	 * @nla: u16 netlink attribute
  1671	 */
  1672	static inline u16 nla_get_u16(const struct nlattr *nla)
  1673	{
  1674		return *(u16 *) nla_data(nla);
  1675	}
  1676	
  1677	/**
  1678	 * nla_get_be16 - return payload of __be16 attribute
  1679	 * @nla: __be16 netlink attribute
  1680	 */
  1681	static inline __be16 nla_get_be16(const struct nlattr *nla)
  1682	{
  1683		return *(__be16 *) nla_data(nla);
  1684	}
  1685	
  1686	/**
  1687	 * nla_get_le16 - return payload of __le16 attribute
  1688	 * @nla: __le16 netlink attribute
  1689	 */
  1690	static inline __le16 nla_get_le16(const struct nlattr *nla)
  1691	{
  1692		return *(__le16 *) nla_data(nla);
  1693	}
  1694	
  1695	/**
  1696	 * nla_get_u8 - return payload of u8 attribute
  1697	 * @nla: u8 netlink attribute
  1698	 */
  1699	static inline u8 nla_get_u8(const struct nlattr *nla)
  1700	{
  1701		return *(u8 *) nla_data(nla);
  1702	}
  1703	
  1704	/**
  1705	 * nla_get_u64 - return payload of u64 attribute
  1706	 * @nla: u64 netlink attribute
  1707	 */
> 1708	static inline u64 nla_get_u64(const struct nlattr *nla)
  1709	{
  1710		u64 tmp;
  1711	
  1712		nla_memcpy(&tmp, nla, sizeof(tmp));
  1713	
  1714		return tmp;
  1715	}
  1716	

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
  2023-10-11  3:20 ` kernel test robot
@ 2023-10-11 13:11 ` Johannes Berg
  2023-10-11 14:03   ` Nicolas Dichtel
  2023-10-11 16:08   ` Jakub Kicinski
  2023-10-11 13:46 ` Jiri Pirko
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 21+ messages in thread
From: Johannes Berg @ 2023-10-11 13:11 UTC (permalink / raw)
  To: Jakub Kicinski, netdev
  Cc: nicolas.dichtel, fw, pablo, jiri, mkubecek, aleksander.lobakin,
	Thomas Haller

+Thomas Haller, if you didn't see it yet.


On Tue, 2023-10-10 at 17:33 -0700, Jakub Kicinski wrote:
> We currently push everyone to use padding to align 64b values in netlink.
> I'm not sure what the story behind this is. I found this:
> https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t
> but it doesn't go into details WRT the motivation.
> Even for arches which don't have good unaligned access - I'd think
> that access aligned to 4B *is* pretty efficient, and that's all
> we need. Plus kernel deals with unaligned input. Why can't user space?

Hmm. I have a vague recollection that it was related to just not doing
it - the kernel will do get_unaligned() or similar, but userspace if it
just accesses it might take a trap on some architectures?

But I can't find any record of this in public discussions, so ...


In any case, I think for _new_ attributes it would be perfectly
acceptable to do it without padding, as long as userspace is prepared to
do unaligned accesses for them, so we might need something in libnl (or
similar) to do it correctly.

> Padded 64b is quite space-inefficient (64b + pad means at worst 16B
> per attr vs 32b which takes 8B). It is also more typing:
> 
>     if (nla_put_u64_pad(rsp, NETDEV_A_SOMETHING_SOMETHING,
>                         value, NETDEV_A_SOMETHING_PAD))
> 
> Create a new attribute type which will use 32 bits at netlink
> level if value is small enough (probably most of the time?),
> and (4B-aligned) 64 bits otherwise. Kernel API is just:
> 
>     if (nla_put_uint(rsp, NETDEV_A_SOMETHING_SOMETHING, value))
> 
> Calling this new type "just" sint / uint with no specific size
> will hopefully also make people more comfortable with using it.
> Currently telling people "don't use u8, you may need the space,
> and netlink will round up to 4B, anyway" is the #1 comment
> we give to newcomers.

Yeah :)

> Thoughts?

Seems reasonable. I thought about endian variants, but with the variable
size that doesn't make much sense.

I do think the documentation in the patch could be clearer about the
alignment, see below.

> +++ b/include/net/netlink.h
> @@ -183,6 +183,8 @@ enum {
>  	NLA_REJECT,
>  	NLA_BE16,
>  	NLA_BE32,
> +	NLA_SINT,
> +	NLA_UINT,

You should also update the policy-related documentation in this file.

> +++ b/include/uapi/linux/netlink.h
> @@ -298,6 +298,8 @@ struct nla_bitfield32 {
>   *	entry has attributes again, the policy for those inner ones
>   *	and the corresponding maxtype may be specified.
>   * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
> + * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
> + * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B

This is only for exposing the policy (policy description), not sure the
alignment thing matters here?

OTOH, there's nothing in this file that ever describes *any* of the
attributes, yet in pracice all the uapi headers do refer to NLA_U8 and
similar - so we should probably have a new comment section here in the
UAPI that describes the various types as used by the documentation of
other families?

Anyway, I think some kind of bigger "careful with alignment" here would
be good, so people do the correct thing and not just "if (big)
nla_get_u64()" which would get the alignment thing problematic again.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
  2023-10-11  3:20 ` kernel test robot
  2023-10-11 13:11 ` Johannes Berg
@ 2023-10-11 13:46 ` Jiri Pirko
  2023-10-11 16:16   ` Jakub Kicinski
  2023-10-12 12:36 ` kernel test robot
  2023-10-14 12:35 ` kernel test robot
  4 siblings, 1 reply; 21+ messages in thread
From: Jiri Pirko @ 2023-10-11 13:46 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: netdev, nicolas.dichtel, johannes, fw, pablo, mkubecek,
	aleksander.lobakin

Wed, Oct 11, 2023 at 02:33:13AM CEST, kuba@kernel.org wrote:
>We currently push everyone to use padding to align 64b values in netlink.
>I'm not sure what the story behind this is. I found this:
>https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t
>but it doesn't go into details WRT the motivation.
>Even for arches which don't have good unaligned access - I'd think
>that access aligned to 4B *is* pretty efficient, and that's all
>we need. Plus kernel deals with unaligned input. Why can't user space?
>
>Padded 64b is quite space-inefficient (64b + pad means at worst 16B
>per attr vs 32b which takes 8B). It is also more typing:
>
>    if (nla_put_u64_pad(rsp, NETDEV_A_SOMETHING_SOMETHING,
>                        value, NETDEV_A_SOMETHING_PAD))
>
>Create a new attribute type which will use 32 bits at netlink
>level if value is small enough (probably most of the time?),
>and (4B-aligned) 64 bits otherwise. Kernel API is just:
>
>    if (nla_put_uint(rsp, NETDEV_A_SOMETHING_SOMETHING, value))
>
>Calling this new type "just" sint / uint with no specific size
>will hopefully also make people more comfortable with using it.
>Currently telling people "don't use u8, you may need the space,
>and netlink will round up to 4B, anyway" is the #1 comment
>we give to newcomers.
>
>In terms of netlink layout it looks like this:
>
>         0       4       8       12      16
>32b:     [nlattr][ u32  ]
>64b:     [  pad ][nlattr][     u64      ]
>uint(32) [nlattr][ u32  ]
>uint(64) [nlattr][     u64      ]
>
>Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>---
>Thoughts?

Hmm, I assume that genetlink.yaml schema should only allow uint and sint
to be defined after this, so new genetlink implementations use just uint
and sint, correct?

Than we have genetlink.yaml genetlink-legacy.yaml genetlink-legacy2.yaml
?
I guess in the future there might be other changes to require new
implemetation not to use legacy things. How does this scale?

+ 2 nits below



>
>This is completely untested. YNL to follow.
>---
> include/net/netlink.h        | 62 ++++++++++++++++++++++++++++++++++--
> include/uapi/linux/netlink.h |  5 +++
> lib/nlattr.c                 |  9 ++++++
> net/netlink/policy.c         | 14 ++++++--
> 4 files changed, 85 insertions(+), 5 deletions(-)
>
>diff --git a/include/net/netlink.h b/include/net/netlink.h
>index 8a7cd1170e1f..523486dfe4f3 100644
>--- a/include/net/netlink.h
>+++ b/include/net/netlink.h
>@@ -183,6 +183,8 @@ enum {
> 	NLA_REJECT,
> 	NLA_BE16,
> 	NLA_BE32,
>+	NLA_SINT,

Why not just NLA_INT?


>+	NLA_UINT,
> 	__NLA_TYPE_MAX,
> };
> 
>@@ -377,9 +379,11 @@ struct nla_policy {
> 
> #define __NLA_IS_UINT_TYPE(tp)					\
> 	(tp == NLA_U8 || tp == NLA_U16 || tp == NLA_U32 ||	\
>-	 tp == NLA_U64 || tp == NLA_BE16 || tp == NLA_BE32)
>+	 tp == NLA_U64 || tp == NLA_UINT ||			\
>+	 tp == NLA_BE16 || tp == NLA_BE32)
> #define __NLA_IS_SINT_TYPE(tp)						\
>-	(tp == NLA_S8 || tp == NLA_S16 || tp == NLA_S32 || tp == NLA_S64)
>+	(tp == NLA_S8 || tp == NLA_S16 || tp == NLA_S32 || tp == NLA_S64 || \
>+	 tp == NLA_SINT)
> 
> #define __NLA_ENSURE(condition) BUILD_BUG_ON_ZERO(!(condition))
> #define NLA_ENSURE_UINT_TYPE(tp)			\
>@@ -1357,6 +1361,22 @@ static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
> 	return nla_put(skb, attrtype, sizeof(u32), &tmp);
> }
> 
>+/**
>+ * nla_put_uint - Add a variable-size unsigned int to a socket buffer
>+ * @skb: socket buffer to add attribute to
>+ * @attrtype: attribute type
>+ * @value: numeric value
>+ */
>+static inline int nla_put_uint(struct sk_buff *skb, int attrtype, u64 value)
>+{
>+	u64 tmp64 = value;
>+	u32 tmp32 = value;
>+
>+	if (tmp64 == tmp32)
>+		return nla_put_u32(skb, attrtype, tmp32);

It's a bit confusing, perheps better just to use nla_put() here as well?

>+	return nla_put(skb, attrtype, sizeof(u64), &tmp64);
>+}
>+
> /**
>  * nla_put_be32 - Add a __be32 netlink attribute to a socket buffer
>  * @skb: socket buffer to add attribute to

[...]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 13:11 ` Johannes Berg
@ 2023-10-11 14:03   ` Nicolas Dichtel
  2023-10-11 15:52     ` Jakub Kicinski
  2023-10-11 16:08   ` Jakub Kicinski
  1 sibling, 1 reply; 21+ messages in thread
From: Nicolas Dichtel @ 2023-10-11 14:03 UTC (permalink / raw)
  To: Johannes Berg, Jakub Kicinski, netdev
  Cc: fw, pablo, jiri, mkubecek, aleksander.lobakin, Thomas Haller

Le 11/10/2023 à 15:11, Johannes Berg a écrit :
> +Thomas Haller, if you didn't see it yet.
> 
> 
> On Tue, 2023-10-10 at 17:33 -0700, Jakub Kicinski wrote:
>> We currently push everyone to use padding to align 64b values in netlink.
>> I'm not sure what the story behind this is. I found this:
>> https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t
There was some attempts before:
https://lore.kernel.org/netdev/20121205.125453.1457654258131828976.davem@davemloft.net/
https://lore.kernel.org/netdev/1355500160.2626.9.camel@bwh-desktop.uk.solarflarecom.com/
https://lore.kernel.org/netdev/1461142655-5067-1-git-send-email-nicolas.dichtel@6wind.com/

>> but it doesn't go into details WRT the motivation.
>> Even for arches which don't have good unaligned access - I'd think
>> that access aligned to 4B *is* pretty efficient, and that's all
>> we need. Plus kernel deals with unaligned input. Why can't user space?
> 
> Hmm. I have a vague recollection that it was related to just not doing
> it - the kernel will do get_unaligned() or similar, but userspace if it
> just accesses it might take a trap on some architectures?
> 
> But I can't find any record of this in public discussions, so ...
If I remember well, at this time, we had some (old) architectures that triggered
traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
to align u64 fields on 8 bytes.


Regards,
Nicolas

> 
> 
> In any case, I think for _new_ attributes it would be perfectly
> acceptable to do it without padding, as long as userspace is prepared to
> do unaligned accesses for them, so we might need something in libnl (or
> similar) to do it correctly.
> 
>> Padded 64b is quite space-inefficient (64b + pad means at worst 16B
>> per attr vs 32b which takes 8B). It is also more typing:
>>
>>     if (nla_put_u64_pad(rsp, NETDEV_A_SOMETHING_SOMETHING,
>>                         value, NETDEV_A_SOMETHING_PAD))
>>
>> Create a new attribute type which will use 32 bits at netlink
>> level if value is small enough (probably most of the time?),
>> and (4B-aligned) 64 bits otherwise. Kernel API is just:
>>
>>     if (nla_put_uint(rsp, NETDEV_A_SOMETHING_SOMETHING, value))
>>
>> Calling this new type "just" sint / uint with no specific size
>> will hopefully also make people more comfortable with using it.
>> Currently telling people "don't use u8, you may need the space,
>> and netlink will round up to 4B, anyway" is the #1 comment
>> we give to newcomers.
> 
> Yeah :)
> 
>> Thoughts?
> 
> Seems reasonable. I thought about endian variants, but with the variable
> size that doesn't make much sense.
> 
> I do think the documentation in the patch could be clearer about the
> alignment, see below.
> 
>> +++ b/include/net/netlink.h
>> @@ -183,6 +183,8 @@ enum {
>>  	NLA_REJECT,
>>  	NLA_BE16,
>>  	NLA_BE32,
>> +	NLA_SINT,
>> +	NLA_UINT,
> 
> You should also update the policy-related documentation in this file.
> 
>> +++ b/include/uapi/linux/netlink.h
>> @@ -298,6 +298,8 @@ struct nla_bitfield32 {
>>   *	entry has attributes again, the policy for those inner ones
>>   *	and the corresponding maxtype may be specified.
>>   * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
>> + * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
>> + * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B
> 
> This is only for exposing the policy (policy description), not sure the
> alignment thing matters here?
> 
> OTOH, there's nothing in this file that ever describes *any* of the
> attributes, yet in pracice all the uapi headers do refer to NLA_U8 and
> similar - so we should probably have a new comment section here in the
> UAPI that describes the various types as used by the documentation of
> other families?
> 
> Anyway, I think some kind of bigger "careful with alignment" here would
> be good, so people do the correct thing and not just "if (big)
> nla_get_u64()" which would get the alignment thing problematic again.
> 
> johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 14:03   ` Nicolas Dichtel
@ 2023-10-11 15:52     ` Jakub Kicinski
  2023-10-11 16:01       ` Johannes Berg
  2023-10-12  6:47       ` Nicolas Dichtel
  0 siblings, 2 replies; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 15:52 UTC (permalink / raw)
  To: Nicolas Dichtel
  Cc: Johannes Berg, netdev, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Thomas Haller

On Wed, 11 Oct 2023 16:03:26 +0200 Nicolas Dichtel wrote:
> > On Tue, 2023-10-10 at 17:33 -0700, Jakub Kicinski wrote:  
> >> We currently push everyone to use padding to align 64b values in netlink.
> >> I'm not sure what the story behind this is. I found this:
> >> https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t  
> There was some attempts before:
> https://lore.kernel.org/netdev/20121205.125453.1457654258131828976.davem@davemloft.net/
> https://lore.kernel.org/netdev/1355500160.2626.9.camel@bwh-desktop.uk.solarflarecom.com/
> https://lore.kernel.org/netdev/1461142655-5067-1-git-send-email-nicolas.dichtel@6wind.com/
> 
> >> but it doesn't go into details WRT the motivation.
> >> Even for arches which don't have good unaligned access - I'd think
> >> that access aligned to 4B *is* pretty efficient, and that's all
> >> we need. Plus kernel deals with unaligned input. Why can't user space?  
> > 
> > Hmm. I have a vague recollection that it was related to just not doing
> > it - the kernel will do get_unaligned() or similar, but userspace if it
> > just accesses it might take a trap on some architectures?
> > 
> > But I can't find any record of this in public discussions, so ...  
> If I remember well, at this time, we had some (old) architectures that triggered
> traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
> between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
> to align u64 fields on 8 bytes.

Reading the discussions I think we can chalk the alignment up 
to "old way of doing things". Discussion was about stats64, 
if someone wants to access stats directly in the message then yes, 
they care a lot about alignment.

Today we try to steer people towards attr-per-field, rather than
dumping structs. Instead of doing:

	struct stats *stats = nla_data(attr);
	print("A: %llu", stats->a);

We will do:

	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));

Assuming nla_get_u64() is unalign-ready the problem doesn't exist.

If user space goes thru a standard parsing library like YNL
the application never even sees the raw netlink message,
and deals with deserialized structs.


Does the above sounds like a fair summary? If so I'll use it in 
the commit message?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 15:52     ` Jakub Kicinski
@ 2023-10-11 16:01       ` Johannes Berg
  2023-10-11 16:45         ` Stephen Hemminger
  2023-10-12  6:47       ` Nicolas Dichtel
  1 sibling, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2023-10-11 16:01 UTC (permalink / raw)
  To: Jakub Kicinski, Nicolas Dichtel
  Cc: netdev, fw, pablo, jiri, mkubecek, aleksander.lobakin, Thomas Haller

On Wed, 2023-10-11 at 08:52 -0700, Jakub Kicinski wrote:

> > > > Even for arches which don't have good unaligned access - I'd think
> > > > that access aligned to 4B *is* pretty efficient, and that's all
> > > > we need. Plus kernel deals with unaligned input. Why can't user space?  
> > > 
> > > Hmm. I have a vague recollection that it was related to just not doing
> > > it - the kernel will do get_unaligned() or similar, but userspace if it
> > > just accesses it might take a trap on some architectures?
> > > 
> > > But I can't find any record of this in public discussions, so ...  
> > If I remember well, at this time, we had some (old) architectures that triggered
> > traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
> > between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
> > to align u64 fields on 8 bytes.
> 
> Reading the discussions I think we can chalk the alignment up 
> to "old way of doing things". Discussion was about stats64, 
> if someone wants to access stats directly in the message then yes, 
> they care a lot about alignment.
> 
> Today we try to steer people towards attr-per-field, rather than
> dumping structs. Instead of doing:
> 
> 	struct stats *stats = nla_data(attr);
> 	print("A: %llu", stats->a);
> 
> We will do:
> 
> 	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));

Well, yes, although the "struct stats" part _still_ even exists in the
kernel, we never fixed that with the nla_put_u64_64bit() stuff, that was
only for something that does

	print("A: %" PRIu64, *(uint64_t *)nla_data(attrs[NLA_BLA_STAT_A]));

> Assuming nla_get_u64() is unalign-ready the problem doesn't exist.

Depends on the library, but at least for libnl that's true since ever.
Same for libmnl and libnl-tiny. So I guess it only ever hit hand-coded
implementations.

For the record, I'm pretty sure (and was at the time) that for wifi
(nl80211) this was never an issue, but ...

> Does the above sounds like a fair summary? If so I'll use it in 
> the commit message?

As I said above, not sure about the whole struct thing - that's still
kind of broken and was never addressed by this, but otherwise yes.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 13:11 ` Johannes Berg
  2023-10-11 14:03   ` Nicolas Dichtel
@ 2023-10-11 16:08   ` Jakub Kicinski
  2023-10-11 16:16     ` Johannes Berg
  1 sibling, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 16:08 UTC (permalink / raw)
  To: Johannes Berg
  Cc: netdev, nicolas.dichtel, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Thomas Haller

On Wed, 11 Oct 2023 15:11:15 +0200 Johannes Berg wrote:
> > +++ b/include/uapi/linux/netlink.h
> > @@ -298,6 +298,8 @@ struct nla_bitfield32 {
> >   *	entry has attributes again, the policy for those inner ones
> >   *	and the corresponding maxtype may be specified.
> >   * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
> > + * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
> > + * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B  
> 
> This is only for exposing the policy (policy description), not sure the
> alignment thing matters here?
> 
> OTOH, there's nothing in this file that ever describes *any* of the
> attributes, yet in pracice all the uapi headers do refer to NLA_U8 and
> similar - so we should probably have a new comment section here in the
> UAPI that describes the various types as used by the documentation of
> other families?
> 
> Anyway, I think some kind of bigger "careful with alignment" here would
> be good, so people do the correct thing and not just "if (big)
> nla_get_u64()" which would get the alignment thing problematic again.

I was planning to add the docs to Documentation/userspace-api/netlink/
Is that too YNL-specific?

diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst
index cc4e2430997e..a8218284e67a 100644
--- a/Documentation/userspace-api/netlink/specs.rst
+++ b/Documentation/userspace-api/netlink/specs.rst
@@ -408,10 +408,21 @@ This section describes the attribute types supported by the ``genetlink``
 compatibility level. Refer to documentation of different levels for additional
 attribute types.
 
-Scalar integer types
+Common integer types
 --------------------
 
-Fixed-width integer types:
+``sint`` and ``uint`` represent signed and unsigned 64 bit integers.
+If the value can fit on 32 bits only 32 bits are carried in netlink
+messages, otherwise full 64 bits are carried. Note that the payload
+is only aligned to 4B, so the full 64 bit value may be unaligned!
+
+Common integer types should be preferred over fix-width types in majority
+of cases.
+
+Fix-width integer types
+-----------------------
+
+Fixed-width integer types include:
 ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, ``s16``, ``s32``, ``s64``.
 
 Note that types smaller than 32 bit should be avoided as using them
@@ -421,6 +432,9 @@ See :ref:`pad_type` for padding of 64 bit attributes.
 The payload of the attribute is the integer in host order unless ``byte-order``
 specifies otherwise.
 
+64 bit values are usually aligned by the kernel but it is recommended
+that the user space is able to deal with unaligned values.
+
 .. _pad_type:
 
 pad

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 13:46 ` Jiri Pirko
@ 2023-10-11 16:16   ` Jakub Kicinski
  2023-10-11 16:21     ` Johannes Berg
  2023-10-11 17:01     ` Jiri Pirko
  0 siblings, 2 replies; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 16:16 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, nicolas.dichtel, johannes, fw, pablo, mkubecek,
	aleksander.lobakin

On Wed, 11 Oct 2023 15:46:47 +0200 Jiri Pirko wrote:
> >Thoughts?  
> 
> Hmm, I assume that genetlink.yaml schema should only allow uint and sint
> to be defined after this, so new genetlink implementations use just uint
> and sint, correct?

No, fixed types are still allowed, just discouraged.

> Than we have genetlink.yaml genetlink-legacy.yaml genetlink-legacy2.yaml
> ?
> I guess in the future there might be other changes to require new
> implemetation not to use legacy things. How does this scale?
>
> >This is completely untested. YNL to follow.
> >---
> > include/net/netlink.h        | 62 ++++++++++++++++++++++++++++++++++--
> > include/uapi/linux/netlink.h |  5 +++
> > lib/nlattr.c                 |  9 ++++++
> > net/netlink/policy.c         | 14 ++++++--
> > 4 files changed, 85 insertions(+), 5 deletions(-)
> >
> >diff --git a/include/net/netlink.h b/include/net/netlink.h
> >index 8a7cd1170e1f..523486dfe4f3 100644
> >--- a/include/net/netlink.h
> >+++ b/include/net/netlink.h
> >@@ -183,6 +183,8 @@ enum {
> > 	NLA_REJECT,
> > 	NLA_BE16,
> > 	NLA_BE32,
> >+	NLA_SINT,  
> 
> Why not just NLA_INT?

Coin toss. Signed types are much less common in netlink
so it shouldn't matter much.

> >+static inline int nla_put_uint(struct sk_buff *skb, int attrtype, u64 value)
> >+{
> >+	u64 tmp64 = value;
> >+	u32 tmp32 = value;
> >+
> >+	if (tmp64 == tmp32)
> >+		return nla_put_u32(skb, attrtype, tmp32);  
> 
> It's a bit confusing, perheps better just to use nla_put() here as well?

I want to underscore the equivalency to u32 for smaller types.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:08   ` Jakub Kicinski
@ 2023-10-11 16:16     ` Johannes Berg
  2023-10-11 16:19       ` Jakub Kicinski
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2023-10-11 16:16 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: netdev, nicolas.dichtel, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Thomas Haller

On Wed, 2023-10-11 at 09:08 -0700, Jakub Kicinski wrote:
> On Wed, 11 Oct 2023 15:11:15 +0200 Johannes Berg wrote:
> > > +++ b/include/uapi/linux/netlink.h
> > > @@ -298,6 +298,8 @@ struct nla_bitfield32 {
> > >   *	entry has attributes again, the policy for those inner ones
> > >   *	and the corresponding maxtype may be specified.
> > >   * @NL_ATTR_TYPE_BITFIELD32: &struct nla_bitfield32 attribute
> > > + * @NL_ATTR_TYPE_SINT: 32-bit or 64-bit signed attribute, aligned to 4B
> > > + * @NL_ATTR_TYPE_UINT: 32-bit or 64-bit unsigned attribute, aligned to 4B  
> > 
> > This is only for exposing the policy (policy description), not sure the
> > alignment thing matters here?
> > 
> > OTOH, there's nothing in this file that ever describes *any* of the
> > attributes, yet in pracice all the uapi headers do refer to NLA_U8 and
> > similar - so we should probably have a new comment section here in the
> > UAPI that describes the various types as used by the documentation of
> > other families?
> > 
> > Anyway, I think some kind of bigger "careful with alignment" here would
> > be good, so people do the correct thing and not just "if (big)
> > nla_get_u64()" which would get the alignment thing problematic again.
> 
> I was planning to add the docs to Documentation/userspace-api/netlink/
> Is that too YNL-specific?

Oh. I guess I keep expecting that header files at least have some hints,
but whatever ... experience tells me anyway that nobody bothers reading
the comments and people just copy stuff from elsewhere, so we just have
to get this right first in one place ;-)

> diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst
> index cc4e2430997e..a8218284e67a 100644
> --- a/Documentation/userspace-api/netlink/specs.rst
> +++ b/Documentation/userspace-api/netlink/specs.rst
> @@ -408,10 +408,21 @@ This section describes the attribute types supported by the ``genetlink``
>  compatibility level. Refer to documentation of different levels for additional
>  attribute types.
>  
> -Scalar integer types
> +Common integer types
>  --------------------
>  
> -Fixed-width integer types:
> +``sint`` and ``uint`` represent signed and unsigned 64 bit integers.
> +If the value can fit on 32 bits only 32 bits are carried in netlink
> +messages, otherwise full 64 bits are carried. Note that the payload
> +is only aligned to 4B, so the full 64 bit value may be unaligned!
> +
> +Common integer types should be preferred over fix-width types in majority
> +of cases.
> +
> +Fix-width integer types
> +-----------------------
> +
> +Fixed-width integer types include:
>  ``u8``, ``u16``, ``u32``, ``u64``, ``s8``, ``s16``, ``s32``, ``s64``.
>  
>  Note that types smaller than 32 bit should be avoided as using them
> @@ -421,6 +432,9 @@ See :ref:`pad_type` for padding of 64 bit attributes.
>  The payload of the attribute is the integer in host order unless ``byte-order``
>  specifies otherwise.
>  
> +64 bit values are usually aligned by the kernel but it is recommended
> +that the user space is able to deal with unaligned values.
> +
>  .. _pad_type:
> 

That does look good though :)

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:16     ` Johannes Berg
@ 2023-10-11 16:19       ` Jakub Kicinski
  0 siblings, 0 replies; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 16:19 UTC (permalink / raw)
  To: Johannes Berg
  Cc: netdev, nicolas.dichtel, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Thomas Haller

On Wed, 11 Oct 2023 18:16:42 +0200 Johannes Berg wrote:
> > I was planning to add the docs to Documentation/userspace-api/netlink/
> > Is that too YNL-specific?  
> 
> Oh. I guess I keep expecting that header files at least have some hints,
> but whatever ... experience tells me anyway that nobody bothers reading
> the comments and people just copy stuff from elsewhere, so we just have
> to get this right first in one place ;-)

I'll try to add something in the header, in that case.
The netlink.h headers are particularly non-conducive
to finding stuff since we have 3 of them :(

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:16   ` Jakub Kicinski
@ 2023-10-11 16:21     ` Johannes Berg
  2023-10-11 16:34       ` Jakub Kicinski
  2023-10-11 17:01     ` Jiri Pirko
  1 sibling, 1 reply; 21+ messages in thread
From: Johannes Berg @ 2023-10-11 16:21 UTC (permalink / raw)
  To: Jakub Kicinski, Jiri Pirko
  Cc: netdev, nicolas.dichtel, fw, pablo, mkubecek, aleksander.lobakin

On Wed, 2023-10-11 at 09:16 -0700, Jakub Kicinski wrote:
> 
> > > +static inline int nla_put_uint(struct sk_buff *skb, int attrtype, u64 value)
> > > +{
> > > +	u64 tmp64 = value;
> > > +	u32 tmp32 = value;
> > > +
> > > +	if (tmp64 == tmp32)
> > > +		return nla_put_u32(skb, attrtype, tmp32);  
> > 
> > It's a bit confusing, perheps better just to use nla_put() here as well?
> 
> I want to underscore the equivalency to u32 for smaller types.

ITYM "smaller values".

Now I'm wondering if we should keep ourselves some option of going to
even bigger values (128 bits) in some potential future, but I guess
that's not really natively supported anywhere in the same way 64-bit is
supposed on 32-bit.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:21     ` Johannes Berg
@ 2023-10-11 16:34       ` Jakub Kicinski
  2023-10-11 16:37         ` Johannes Berg
  0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 16:34 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Jiri Pirko, netdev, nicolas.dichtel, fw, pablo, mkubecek,
	aleksander.lobakin

On Wed, 11 Oct 2023 18:21:47 +0200 Johannes Berg wrote:
> > > It's a bit confusing, perheps better just to use nla_put() here as well?  
> > 
> > I want to underscore the equivalency to u32 for smaller types.  
> 
> ITYM "smaller values".

Right, sorry.

> Now I'm wondering if we should keep ourselves some option of going to
> even bigger values (128 bits) in some potential future, but I guess
> that's not really natively supported anywhere in the same way 64-bit is
> supposed on 32-bit.

I was wondering the same. And in fact that's what kept me from posting
this patch for like a year. Initially I was envisioning a Python-style
bigint, then at least a 128b int, then I gave up.

The problem is I have no idea how to handle large types in C.
Would nla_get_uint() then return uint128_t?  YNL also needs to turn the
value into the max width type and put it in a "parsed response struct".
Presumably that'd also have to render all uints as uint128_t..

If we can't make the consumers reliably handle 128b there's no point 
in pretending that more than 64b can be carried. 
I'm not even sure if all 32b arches support u128.

Given that we have 0 uses of 128b integers in netlink today, I figured
we're better off crossing that bridge when we get there..

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:34       ` Jakub Kicinski
@ 2023-10-11 16:37         ` Johannes Berg
  0 siblings, 0 replies; 21+ messages in thread
From: Johannes Berg @ 2023-10-11 16:37 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Jiri Pirko, netdev, nicolas.dichtel, fw, pablo, mkubecek,
	aleksander.lobakin

On Wed, 2023-10-11 at 09:34 -0700, Jakub Kicinski wrote:
> 
> > Now I'm wondering if we should keep ourselves some option of going to
> > even bigger values (128 bits) in some potential future, but I guess
> > that's not really natively supported anywhere in the same way 64-bit is
> > supposed on 32-bit.

s/supposed/supported/, sorry.

> I was wondering the same. And in fact that's what kept me from posting
> this patch for like a year. Initially I was envisioning a Python-style
> bigint, then at least a 128b int, then I gave up.
> 
> The problem is I have no idea how to handle large types in C.
> Would nla_get_uint() then return uint128_t?  YNL also needs to turn the
> value into the max width type and put it in a "parsed response struct".
> Presumably that'd also have to render all uints as uint128_t..
> 
> If we can't make the consumers reliably handle 128b there's no point 
> in pretending that more than 64b can be carried. 
> I'm not even sure if all 32b arches support u128.

Oh, right, I hadn't even thought about that you need to use the max
width type for return values and arguments.

> Given that we have 0 uses of 128b integers in netlink today, I figured
> we're better off crossing that bridge when we get there..

Agreed. It probably means new types at the time, but that might well be
far off anyway.

johannes

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:01       ` Johannes Berg
@ 2023-10-11 16:45         ` Stephen Hemminger
  2023-10-12  9:26           ` David Laight
  0 siblings, 1 reply; 21+ messages in thread
From: Stephen Hemminger @ 2023-10-11 16:45 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Jakub Kicinski, Nicolas Dichtel, netdev, fw, pablo, jiri,
	mkubecek, aleksander.lobakin, Thomas Haller

On Wed, 11 Oct 2023 18:01:49 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Wed, 2023-10-11 at 08:52 -0700, Jakub Kicinski wrote:
> 
> > > > > Even for arches which don't have good unaligned access - I'd think
> > > > > that access aligned to 4B *is* pretty efficient, and that's all
> > > > > we need. Plus kernel deals with unaligned input. Why can't user space?    
> > > > 
> > > > Hmm. I have a vague recollection that it was related to just not doing
> > > > it - the kernel will do get_unaligned() or similar, but userspace if it
> > > > just accesses it might take a trap on some architectures?
> > > > 
> > > > But I can't find any record of this in public discussions, so ...    
> > > If I remember well, at this time, we had some (old) architectures that triggered
> > > traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
> > > between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
> > > to align u64 fields on 8 bytes.  
> > 
> > Reading the discussions I think we can chalk the alignment up 
> > to "old way of doing things". Discussion was about stats64, 
> > if someone wants to access stats directly in the message then yes, 
> > they care a lot about alignment.
> > 
> > Today we try to steer people towards attr-per-field, rather than
> > dumping structs. Instead of doing:
> > 
> > 	struct stats *stats = nla_data(attr);
> > 	print("A: %llu", stats->a);
> > 
> > We will do:
> > 
> > 	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));  
> 
> Well, yes, although the "struct stats" part _still_ even exists in the
> kernel, we never fixed that with the nla_put_u64_64bit() stuff, that was
> only for something that does
> 
> 	print("A: %" PRIu64, *(uint64_t *)nla_data(attrs[NLA_BLA_STAT_A]));
> 
> > Assuming nla_get_u64() is unalign-ready the problem doesn't exist.  
> 
> Depends on the library, but at least for libnl that's true since ever.
> Same for libmnl and libnl-tiny. So I guess it only ever hit hand-coded
> implementations.

Quick check of iproute2 shows places where stats are directly
mapped without accessors. One example is print_mpls_stats().

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:16   ` Jakub Kicinski
  2023-10-11 16:21     ` Johannes Berg
@ 2023-10-11 17:01     ` Jiri Pirko
  2023-10-11 20:21       ` Jakub Kicinski
  1 sibling, 1 reply; 21+ messages in thread
From: Jiri Pirko @ 2023-10-11 17:01 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: netdev, nicolas.dichtel, johannes, fw, pablo, mkubecek,
	aleksander.lobakin

Wed, Oct 11, 2023 at 06:16:24PM CEST, kuba@kernel.org wrote:
>On Wed, 11 Oct 2023 15:46:47 +0200 Jiri Pirko wrote:
>> >Thoughts?  
>> 
>> Hmm, I assume that genetlink.yaml schema should only allow uint and sint
>> to be defined after this, so new genetlink implementations use just uint
>> and sint, correct?
>
>No, fixed types are still allowed, just discouraged.

Why? Is there goint to be warn in ynl gen?

>
>> Than we have genetlink.yaml genetlink-legacy.yaml genetlink-legacy2.yaml
>> ?
>> I guess in the future there might be other changes to require new
>> implemetation not to use legacy things. How does this scale?
>>
>> >This is completely untested. YNL to follow.
>> >---
>> > include/net/netlink.h        | 62 ++++++++++++++++++++++++++++++++++--
>> > include/uapi/linux/netlink.h |  5 +++
>> > lib/nlattr.c                 |  9 ++++++
>> > net/netlink/policy.c         | 14 ++++++--
>> > 4 files changed, 85 insertions(+), 5 deletions(-)
>> >
>> >diff --git a/include/net/netlink.h b/include/net/netlink.h
>> >index 8a7cd1170e1f..523486dfe4f3 100644
>> >--- a/include/net/netlink.h
>> >+++ b/include/net/netlink.h
>> >@@ -183,6 +183,8 @@ enum {
>> > 	NLA_REJECT,
>> > 	NLA_BE16,
>> > 	NLA_BE32,
>> >+	NLA_SINT,  
>> 
>> Why not just NLA_INT?
>
>Coin toss. Signed types are much less common in netlink
>so it shouldn't matter much.
>
>> >+static inline int nla_put_uint(struct sk_buff *skb, int attrtype, u64 value)
>> >+{
>> >+	u64 tmp64 = value;
>> >+	u32 tmp32 = value;
>> >+
>> >+	if (tmp64 == tmp32)
>> >+		return nla_put_u32(skb, attrtype, tmp32);  
>> 
>> It's a bit confusing, perheps better just to use nla_put() here as well?
>
>I want to underscore the equivalency to u32 for smaller types.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 17:01     ` Jiri Pirko
@ 2023-10-11 20:21       ` Jakub Kicinski
  0 siblings, 0 replies; 21+ messages in thread
From: Jakub Kicinski @ 2023-10-11 20:21 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, nicolas.dichtel, johannes, fw, pablo, mkubecek,
	aleksander.lobakin

On Wed, 11 Oct 2023 19:01:53 +0200 Jiri Pirko wrote:
> Wed, Oct 11, 2023 at 06:16:24PM CEST, kuba@kernel.org wrote:
> >No, fixed types are still allowed, just discouraged.  
> 
> Why?

The only legit use case that comes to mind is protocol
fields which have strictly-defined size. People like
to mirror their size into netlink, for better or worse.

> Is there goint to be warn in ynl gen?

Just a comment in the docs:

https://lore.kernel.org/all/20231011090859.3fc30812@kernel.org/


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11 15:52     ` Jakub Kicinski
  2023-10-11 16:01       ` Johannes Berg
@ 2023-10-12  6:47       ` Nicolas Dichtel
  1 sibling, 0 replies; 21+ messages in thread
From: Nicolas Dichtel @ 2023-10-12  6:47 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Johannes Berg, netdev, fw, pablo, jiri, mkubecek,
	aleksander.lobakin, Thomas Haller



Le 11/10/2023 à 17:52, Jakub Kicinski a écrit :
> On Wed, 11 Oct 2023 16:03:26 +0200 Nicolas Dichtel wrote:
>>> On Tue, 2023-10-10 at 17:33 -0700, Jakub Kicinski wrote:  
>>>> We currently push everyone to use padding to align 64b values in netlink.
>>>> I'm not sure what the story behind this is. I found this:
>>>> https://lore.kernel.org/all/1461339084-3849-1-git-send-email-nicolas.dichtel@6wind.com/#t  
>> There was some attempts before:
>> https://lore.kernel.org/netdev/20121205.125453.1457654258131828976.davem@davemloft.net/
>> https://lore.kernel.org/netdev/1355500160.2626.9.camel@bwh-desktop.uk.solarflarecom.com/
>> https://lore.kernel.org/netdev/1461142655-5067-1-git-send-email-nicolas.dichtel@6wind.com/
>>
>>>> but it doesn't go into details WRT the motivation.
>>>> Even for arches which don't have good unaligned access - I'd think
>>>> that access aligned to 4B *is* pretty efficient, and that's all
>>>> we need. Plus kernel deals with unaligned input. Why can't user space?  
>>>
>>> Hmm. I have a vague recollection that it was related to just not doing
>>> it - the kernel will do get_unaligned() or similar, but userspace if it
>>> just accesses it might take a trap on some architectures?
>>>
>>> But I can't find any record of this in public discussions, so ...  
>> If I remember well, at this time, we had some (old) architectures that triggered
>> traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
>> between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
>> to align u64 fields on 8 bytes.
> 
> Reading the discussions I think we can chalk the alignment up 
> to "old way of doing things". Discussion was about stats64, 
> if someone wants to access stats directly in the message then yes, 
> they care a lot about alignment.
> 
> Today we try to steer people towards attr-per-field, rather than
> dumping structs. Instead of doing:
> 
> 	struct stats *stats = nla_data(attr);
> 	print("A: %llu", stats->a);
> 
> We will do:
> 
> 	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));
> 
> Assuming nla_get_u64() is unalign-ready the problem doesn't exist.
> 
> If user space goes thru a standard parsing library like YNL
> the application never even sees the raw netlink message,
> and deals with deserialized structs.
> 
> 
> Does the above sounds like a fair summary? If so I'll use it in 
> the commit message?
I think it is, it's ok for me.


Thank you,
Nicolas

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: [RFC] netlink: add variable-length / auto integers
  2023-10-11 16:45         ` Stephen Hemminger
@ 2023-10-12  9:26           ` David Laight
  0 siblings, 0 replies; 21+ messages in thread
From: David Laight @ 2023-10-12  9:26 UTC (permalink / raw)
  To: 'Stephen Hemminger', Johannes Berg
  Cc: Jakub Kicinski, Nicolas Dichtel, netdev, fw, pablo, jiri,
	mkubecek, aleksander.lobakin, Thomas Haller

From: Stephen Hemminger
> Sent: 11 October 2023 17:46
> 
> On Wed, 11 Oct 2023 18:01:49 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > On Wed, 2023-10-11 at 08:52 -0700, Jakub Kicinski wrote:
> >
> > > > > > Even for arches which don't have good unaligned access - I'd think
> > > > > > that access aligned to 4B *is* pretty efficient, and that's all
> > > > > > we need. Plus kernel deals with unaligned input. Why can't user space?
> > > > >
> > > > > Hmm. I have a vague recollection that it was related to just not doing
> > > > > it - the kernel will do get_unaligned() or similar, but userspace if it
> > > > > just accesses it might take a trap on some architectures?
> > > > >
> > > > > But I can't find any record of this in public discussions, so ...
> > > > If I remember well, at this time, we had some (old) architectures that triggered
> > > > traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
> > > > between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
> > > > to align u64 fields on 8 bytes.
> > >
> > > Reading the discussions I think we can chalk the alignment up
> > > to "old way of doing things". Discussion was about stats64,
> > > if someone wants to access stats directly in the message then yes,
> > > they care a lot about alignment.
> > >
> > > Today we try to steer people towards attr-per-field, rather than
> > > dumping structs. Instead of doing:
> > >
> > > 	struct stats *stats = nla_data(attr);
> > > 	print("A: %llu", stats->a);
> > >
> > > We will do:
> > >
> > > 	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));
> >
> > Well, yes, although the "struct stats" part _still_ even exists in the
> > kernel, we never fixed that with the nla_put_u64_64bit() stuff, that was
> > only for something that does
> >
> > 	print("A: %" PRIu64, *(uint64_t *)nla_data(attrs[NLA_BLA_STAT_A]));
> >
> > > Assuming nla_get_u64() is unalign-ready the problem doesn't exist.
> >
> > Depends on the library, but at least for libnl that's true since ever.
> > Same for libmnl and libnl-tiny. So I guess it only ever hit hand-coded
> > implementations.
> 
> Quick check of iproute2 shows places where stats are directly
> mapped without accessors. One example is print_mpls_stats().

You 'just' need to use the 64bit type that has __attribute__((aligned(4))).
The same is true for the code that reads/writes the value.
Better than passing by address and using memcpy();

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
                   ` (2 preceding siblings ...)
  2023-10-11 13:46 ` Jiri Pirko
@ 2023-10-12 12:36 ` kernel test robot
  2023-10-14 12:35 ` kernel test robot
  4 siblings, 0 replies; 21+ messages in thread
From: kernel test robot @ 2023-10-12 12:36 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: oe-kbuild-all

Hi Jakub,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on net/main]
[also build test ERROR on net-next/main linus/master v6.6-rc5 next-20231012]
[cannot apply to horms-ipvs/master]
[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/Jakub-Kicinski/netlink-add-variable-length-auto-integers/20231011-083419
base:   net/main
patch link:    https://lore.kernel.org/r/20231011003313.105315-1-kuba%40kernel.org
patch subject: [RFC] netlink: add variable-length / auto integers
config: um-i386_defconfig (https://download.01.org/0day-ci/archive/20231012/202310122018.E8b1ottR-lkp@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231012/202310122018.E8b1ottR-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/202310122018.E8b1ottR-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from include/linux/tcp.h:19,
                    from include/linux/ipv6.h:94,
                    from include/net/ipv6.h:12,
                    from include/linux/sunrpc/clnt.h:29,
                    from include/linux/nfs_fs.h:32,
                    from init/do_mounts.c:23:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from include/linux/tcp.h:19,
                    from include/linux/ipv6.h:94,
                    from include/net/addrconf.h:52,
                    from lib/vsprintf.c:41:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   lib/vsprintf.c: In function 'va_format':
   lib/vsprintf.c:1682:2: warning: function 'va_format' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]
     buf += vsnprintf(buf, end > buf ? end - buf : 0, va_fmt->fmt, va);
     ^~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/neighbour.h:31,
                    from include/net/dst.h:20,
                    from include/net/sock.h:66,
                    from include/linux/bpf-cgroup.h:11,
                    from net/socket.c:55:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   net/socket.c:1696:21: warning: no previous declaration for 'update_socket_protocol' [-Wmissing-declarations]
    __weak noinline int update_socket_protocol(int family, int type, int protocol)
                        ^~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/sch_generic.h:20,
                    from include/linux/filter.h:27,
                    from include/linux/bpf_verifier.h:9,
                    from net/core/filter.c:21:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   net/core/filter.c:11730:17: warning: no previous declaration for 'bpf_dynptr_from_skb' [-Wmissing-declarations]
    __bpf_kfunc int bpf_dynptr_from_skb(struct sk_buff *skb, u64 flags,
                    ^~~~~~~~~~~~~~~~~~~
   net/core/filter.c:11743:17: warning: no previous declaration for 'bpf_dynptr_from_xdp' [-Wmissing-declarations]
    __bpf_kfunc int bpf_dynptr_from_xdp(struct xdp_buff *xdp, u64 flags,
                    ^~~~~~~~~~~~~~~~~~~
   net/core/filter.c:11828:17: warning: no previous declaration for 'bpf_sock_destroy' [-Wmissing-declarations]
    __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)
                    ^~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/sch_generic.h:20,
                    from include/linux/filter.h:27,
                    from net/core/xdp.c:9:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   net/core/xdp.c:713:17: warning: no previous declaration for 'bpf_xdp_metadata_rx_timestamp' [-Wmissing-declarations]
    __bpf_kfunc int bpf_xdp_metadata_rx_timestamp(const struct xdp_md *ctx, u64 *timestamp)
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   net/core/xdp.c:735:17: warning: no previous declaration for 'bpf_xdp_metadata_rx_hash' [-Wmissing-declarations]
    __bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32 *hash,
                    ^~~~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors
--
   In file included from include/net/rtnetlink.h:6:0,
                    from include/net/fib_rules.h:11,
                    from include/linux/mroute.h:7,
                    from net/ipv4/route.c:79:
   include/net/netlink.h: In function 'nla_get_uint':
   include/net/netlink.h:1647:9: error: implicit declaration of function 'nla_get_u64'; did you mean 'nla_get_u32'? [-Werror=implicit-function-declaration]
     return nla_get_u64(nla);
            ^~~~~~~~~~~
            nla_get_u32
   include/net/netlink.h: At top level:
>> include/net/netlink.h:1708:19: error: conflicting types for 'nla_get_u64'
    static inline u64 nla_get_u64(const struct nlattr *nla)
                      ^~~~~~~~~~~
   include/net/netlink.h:1647:9: note: previous implicit declaration of 'nla_get_u64' was here
     return nla_get_u64(nla);
            ^~~~~~~~~~~
   net/ipv4/route.c: In function 'ip_rt_send_redirect':
   net/ipv4/route.c:880:6: warning: variable 'log_martians' set but not used [-Wunused-but-set-variable]
     int log_martians;
         ^~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/nla_get_u64 +1708 include/net/netlink.h

bfa83a9e03cf8d Thomas Graf     2005-11-10  1703  
bfa83a9e03cf8d Thomas Graf     2005-11-10  1704  /**
bfa83a9e03cf8d Thomas Graf     2005-11-10  1705   * nla_get_u64 - return payload of u64 attribute
bfa83a9e03cf8d Thomas Graf     2005-11-10  1706   * @nla: u64 netlink attribute
bfa83a9e03cf8d Thomas Graf     2005-11-10  1707   */
b057efd4d226fc Patrick McHardy 2008-10-28 @1708  static inline u64 nla_get_u64(const struct nlattr *nla)
bfa83a9e03cf8d Thomas Graf     2005-11-10  1709  {
bfa83a9e03cf8d Thomas Graf     2005-11-10  1710  	u64 tmp;
bfa83a9e03cf8d Thomas Graf     2005-11-10  1711  
bfa83a9e03cf8d Thomas Graf     2005-11-10  1712  	nla_memcpy(&tmp, nla, sizeof(tmp));
bfa83a9e03cf8d Thomas Graf     2005-11-10  1713  
bfa83a9e03cf8d Thomas Graf     2005-11-10  1714  	return tmp;
bfa83a9e03cf8d Thomas Graf     2005-11-10  1715  }
bfa83a9e03cf8d Thomas Graf     2005-11-10  1716  

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [RFC] netlink: add variable-length / auto integers
  2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
                   ` (3 preceding siblings ...)
  2023-10-12 12:36 ` kernel test robot
@ 2023-10-14 12:35 ` kernel test robot
  4 siblings, 0 replies; 21+ messages in thread
From: kernel test robot @ 2023-10-14 12:35 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: llvm, oe-kbuild-all

Hi Jakub,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on net/main]
[also build test WARNING on net-next/main linus/master v6.6-rc5 next-20231013]
[cannot apply to horms-ipvs/master]
[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/Jakub-Kicinski/netlink-add-variable-length-auto-integers/20231011-083419
base:   net/main
patch link:    https://lore.kernel.org/r/20231011003313.105315-1-kuba%40kernel.org
patch subject: [RFC] netlink: add variable-length / auto integers
config: x86_64-rhel-8.3-rust (https://download.01.org/0day-ci/archive/20231014/202310142003.fYeLpu4J-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231014/202310142003.fYeLpu4J-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/202310142003.fYeLpu4J-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from drivers/net/ethernet/intel/e1000e/netdev.c:15:
   In file included from include/linux/tcp.h:19:
   In file included from include/net/sock.h:66:
   In file included from include/net/dst.h:20:
   In file included from include/net/neighbour.h:31:
   In file included from include/net/rtnetlink.h:6:
   include/net/netlink.h:1647:9: error: call to undeclared function 'nla_get_u64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           return nla_get_u64(nla);
                  ^
   include/net/netlink.h:1647:9: note: did you mean 'nla_get_u32'?
   include/net/netlink.h:1634:19: note: 'nla_get_u32' declared here
   static inline u32 nla_get_u32(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1708:19: error: static declaration of 'nla_get_u64' follows non-static declaration
   static inline u64 nla_get_u64(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1647:9: note: previous implicit declaration is here
           return nla_get_u64(nla);
                  ^
>> drivers/net/ethernet/intel/e1000e/netdev.c:4462:22: warning: shift count >= width of type [-Wshift-count-overflow]
                   adapter->cc.mask = CYCLECOUNTER_MASK(64);
                                      ^~~~~~~~~~~~~~~~~~~~~
   include/linux/timecounter.h:14:59: note: expanded from macro 'CYCLECOUNTER_MASK'
   #define CYCLECOUNTER_MASK(bits) (u64)((bits) < 64 ? ((1ULL<<(bits))-1) : -1)
                                                             ^ ~~~~~~
   drivers/net/ethernet/intel/e1000e/netdev.c:7386:46: warning: shift count >= width of type [-Wshift-count-overflow]
           err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
                                                       ^~~~~~~~~~~~~~~~
   include/linux/dma-mapping.h:77:54: note: expanded from macro 'DMA_BIT_MASK'
   #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                        ^ ~~~
   2 warnings and 2 errors generated.
--
   In file included from drivers/net/ethernet/intel/igb/igb_main.c:13:
   In file included from include/linux/ipv6.h:94:
   In file included from include/linux/tcp.h:19:
   In file included from include/net/sock.h:66:
   In file included from include/net/dst.h:20:
   In file included from include/net/neighbour.h:31:
   In file included from include/net/rtnetlink.h:6:
   include/net/netlink.h:1647:9: error: call to undeclared function 'nla_get_u64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           return nla_get_u64(nla);
                  ^
   include/net/netlink.h:1647:9: note: did you mean 'nla_get_u32'?
   include/net/netlink.h:1634:19: note: 'nla_get_u32' declared here
   static inline u32 nla_get_u32(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1708:19: error: static declaration of 'nla_get_u64' follows non-static declaration
   static inline u64 nla_get_u64(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1647:9: note: previous implicit declaration is here
           return nla_get_u64(nla);
                  ^
   drivers/net/ethernet/intel/igb/igb_main.c:3226:46: warning: shift count >= width of type [-Wshift-count-overflow]
           err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
                                                       ^~~~~~~~~~~~~~~~
   include/linux/dma-mapping.h:77:54: note: expanded from macro 'DMA_BIT_MASK'
   #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                        ^ ~~~
>> drivers/net/ethernet/intel/igb/igb_main.c:6132:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGB_SET_FLAG(tx_flags, IGB_TX_FLAGS_VLAN,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6136:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGB_SET_FLAG(tx_flags, IGB_TX_FLAGS_TSO,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6140:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGB_SET_FLAG(tx_flags, IGB_TX_FLAGS_TSTAMP,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6144:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type ^= IGB_SET_FLAG(skb->no_fcs, 1, E1000_ADVTXD_DCMD_IFCS);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6160:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IGB_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6165:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IGB_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igb/igb_main.c:6122:26: note: expanded from macro 'IGB_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   7 warnings and 2 errors generated.
--
   In file included from drivers/net/ethernet/intel/igb/igb_ptp.c:7:
   In file included from include/linux/ptp_classify.h:17:
   In file included from include/linux/udp.h:16:
   In file included from include/net/inet_sock.h:22:
   In file included from include/net/sock.h:66:
   In file included from include/net/dst.h:20:
   In file included from include/net/neighbour.h:31:
   In file included from include/net/rtnetlink.h:6:
   include/net/netlink.h:1647:9: error: call to undeclared function 'nla_get_u64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           return nla_get_u64(nla);
                  ^
   include/net/netlink.h:1647:9: note: did you mean 'nla_get_u32'?
   include/net/netlink.h:1634:19: note: 'nla_get_u32' declared here
   static inline u32 nla_get_u32(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1708:19: error: static declaration of 'nla_get_u64' follows non-static declaration
   static inline u64 nla_get_u64(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1647:9: note: previous implicit declaration is here
           return nla_get_u64(nla);
                  ^
>> drivers/net/ethernet/intel/igb/igb_ptp.c:1336:22: warning: shift count >= width of type [-Wshift-count-overflow]
                   adapter->cc.mask = CYCLECOUNTER_MASK(64);
                                      ^~~~~~~~~~~~~~~~~~~~~
   include/linux/timecounter.h:14:59: note: expanded from macro 'CYCLECOUNTER_MASK'
   #define CYCLECOUNTER_MASK(bits) (u64)((bits) < 64 ? ((1ULL<<(bits))-1) : -1)
                                                             ^ ~~~~~~
   1 warning and 2 errors generated.
--
   In file included from drivers/net/ethernet/intel/igc/igc_main.c:7:
   In file included from include/linux/tcp.h:19:
   In file included from include/net/sock.h:66:
   In file included from include/net/dst.h:20:
   In file included from include/net/neighbour.h:31:
   In file included from include/net/rtnetlink.h:6:
   include/net/netlink.h:1647:9: error: call to undeclared function 'nla_get_u64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           return nla_get_u64(nla);
                  ^
   include/net/netlink.h:1647:9: note: did you mean 'nla_get_u32'?
   include/net/netlink.h:1634:19: note: 'nla_get_u32' declared here
   static inline u32 nla_get_u32(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1708:19: error: static declaration of 'nla_get_u64' follows non-static declaration
   static inline u64 nla_get_u64(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1647:9: note: previous implicit declaration is here
           return nla_get_u64(nla);
                  ^
>> drivers/net/ethernet/intel/igc/igc_main.c:1267:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_VLAN,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1271:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_TSO,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1277:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_TSTAMP,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1280:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_TSTAMP_1,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1283:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_TSTAMP_2,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1286:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IGC_SET_FLAG(tx_flags, IGC_TX_FLAGS_TSTAMP_3,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1290:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type ^= IGC_SET_FLAG(skb->no_fcs, 1, IGC_ADVTXD_DCMD_IFCS);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:1257:30: note: expanded from macro 'IGC_SET_FLAG'
            ((u32)((_input) & (_flag)) / ((_flag) / (_result))))
                                       ^ ~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/igc/igc_main.c:6751:46: warning: shift count >= width of type [-Wshift-count-overflow]
           err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
                                                       ^~~~~~~~~~~~~~~~
   include/linux/dma-mapping.h:77:54: note: expanded from macro 'DMA_BIT_MASK'
   #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                        ^ ~~~
   8 warnings and 2 errors generated.
--
   In file included from drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:13:
   In file included from include/linux/tcp.h:19:
   In file included from include/net/sock.h:66:
   In file included from include/net/dst.h:20:
   In file included from include/net/neighbour.h:31:
   In file included from include/net/rtnetlink.h:6:
   include/net/netlink.h:1647:9: error: call to undeclared function 'nla_get_u64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
           return nla_get_u64(nla);
                  ^
   include/net/netlink.h:1647:9: note: did you mean 'nla_get_u32'?
   include/net/netlink.h:1634:19: note: 'nla_get_u32' declared here
   static inline u32 nla_get_u32(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1708:19: error: static declaration of 'nla_get_u64' follows non-static declaration
   static inline u64 nla_get_u64(const struct nlattr *nla)
                     ^
   include/net/netlink.h:1647:9: note: previous implicit declaration is here
           return nla_get_u64(nla);
                  ^
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8219:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_HW_VLAN,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8223:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_TSO,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8227:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_TSTAMP,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8231:14: warning: division by zero is undefined [-Wdivision-by-zero]
           cmd_type ^= IXGBE_SET_FLAG(skb->no_fcs, 1, IXGBE_ADVTXD_DCMD_IFCS);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8242:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IXGBE_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8247:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IXGBE_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8252:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IXGBE_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8260:19: warning: division by zero is undefined [-Wdivision-by-zero]
           olinfo_status |= IXGBE_SET_FLAG(tx_flags,
                            ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8209:26: note: expanded from macro 'IXGBE_SET_FLAG'
            ((u32)(_input & _flag) / (_flag / _result)))
                                   ^ ~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:10786:46: warning: shift count >= width of type [-Wshift-count-overflow]
           err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
                                                       ^~~~~~~~~~~~~~~~
   include/linux/dma-mapping.h:77:54: note: expanded from macro 'DMA_BIT_MASK'
   #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
                                                        ^ ~~~
   9 warnings and 2 errors generated.


vim +4462 drivers/net/ethernet/intel/e1000e/netdev.c

98942d70538a16 drivers/net/ethernet/intel/e1000e/netdev.c Miroslav Lichvar 2018-11-09  4432  
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4433  /**
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4434   * e1000_sw_init - Initialize general software structures (struct e1000_adapter)
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4435   * @adapter: board private structure to initialize
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4436   *
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4437   * e1000_sw_init initializes the Adapter private data structure.
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4438   * Fields are initialized based on PCI device information and
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4439   * OS network device settings (MTU size).
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4440   **/
9f9a12f8ca7983 drivers/net/ethernet/intel/e1000e/netdev.c Bill Pemberton   2012-12-03  4441  static int e1000_sw_init(struct e1000_adapter *adapter)
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4442  {
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4443  	struct net_device *netdev = adapter->netdev;
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4444  
8084b86dcfbc4b drivers/net/ethernet/intel/e1000e/netdev.c Alexander Duyck  2015-05-02  4445  	adapter->rx_buffer_len = VLAN_ETH_FRAME_LEN + ETH_FCS_LEN;
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4446  	adapter->rx_ps_bsize0 = 128;
8084b86dcfbc4b drivers/net/ethernet/intel/e1000e/netdev.c Alexander Duyck  2015-05-02  4447  	adapter->max_frame_size = netdev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
318a94d68979cb drivers/net/e1000e/netdev.c                Jeff Kirsher     2008-03-28  4448  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
55aa69854a93d7 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2011-12-16  4449  	adapter->tx_ring_count = E1000_DEFAULT_TXD;
55aa69854a93d7 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2011-12-16  4450  	adapter->rx_ring_count = E1000_DEFAULT_RXD;
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4451  
67fd4fcb78a7ce drivers/net/e1000e/netdev.c                Jeff Kirsher     2011-01-07  4452  	spin_lock_init(&adapter->stats64_lock);
67fd4fcb78a7ce drivers/net/e1000e/netdev.c                Jeff Kirsher     2011-01-07  4453  
4662e82b2cb41c drivers/net/e1000e/netdev.c                Bruce Allan      2008-08-26  4454  	e1000e_set_interrupt_capability(adapter);
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4455  
4662e82b2cb41c drivers/net/e1000e/netdev.c                Bruce Allan      2008-08-26  4456  	if (e1000_alloc_queues(adapter))
4662e82b2cb41c drivers/net/e1000e/netdev.c                Bruce Allan      2008-08-26  4457  		return -ENOMEM;
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4458  
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4459  	/* Setup hardware time stamping cyclecounter */
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4460  	if (adapter->flags & FLAG_HAS_HW_TIMESTAMP) {
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4461  		adapter->cc.read = e1000e_cyclecounter_read;
4d045b4c06b1f7 drivers/net/ethernet/intel/e1000e/netdev.c Richard Cochran  2015-01-02 @4462  		adapter->cc.mask = CYCLECOUNTER_MASK(64);
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4463  		adapter->cc.mult = 1;
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4464  		/* cc.shift set in e1000e_get_base_tininca() */
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4465  
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4466  		spin_lock_init(&adapter->systim_lock);
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4467  		INIT_WORK(&adapter->tx_hwtstamp_work, e1000e_tx_hwtstamp_work);
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4468  	}
b67e191307a3f3 drivers/net/ethernet/intel/e1000e/netdev.c Bruce Allan      2012-12-27  4469  
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4470  	/* Explicitly disable IRQ since the NIC can be in any state. */
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4471  	e1000_irq_disable(adapter);
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4472  
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4473  	set_bit(__E1000_DOWN, &adapter->state);
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4474  	return 0;
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4475  }
bc7f75fa97884d drivers/net/e1000e/netdev.c                Auke Kok         2007-09-17  4476  

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2023-10-14 12:36 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-11  0:33 [RFC] netlink: add variable-length / auto integers Jakub Kicinski
2023-10-11  3:20 ` kernel test robot
2023-10-11 13:11 ` Johannes Berg
2023-10-11 14:03   ` Nicolas Dichtel
2023-10-11 15:52     ` Jakub Kicinski
2023-10-11 16:01       ` Johannes Berg
2023-10-11 16:45         ` Stephen Hemminger
2023-10-12  9:26           ` David Laight
2023-10-12  6:47       ` Nicolas Dichtel
2023-10-11 16:08   ` Jakub Kicinski
2023-10-11 16:16     ` Johannes Berg
2023-10-11 16:19       ` Jakub Kicinski
2023-10-11 13:46 ` Jiri Pirko
2023-10-11 16:16   ` Jakub Kicinski
2023-10-11 16:21     ` Johannes Berg
2023-10-11 16:34       ` Jakub Kicinski
2023-10-11 16:37         ` Johannes Berg
2023-10-11 17:01     ` Jiri Pirko
2023-10-11 20:21       ` Jakub Kicinski
2023-10-12 12:36 ` kernel test robot
2023-10-14 12:35 ` kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.