Update the docs to match the code (include/linux/netlink.h):

  /*
   *	skb should fit one page. This choice is good for headerless malloc.
   *	But we should limit to 8K so that userspace does not have to
   *	use enormous buffer sizes on recvmsg() calls just to avoid
   *	MSG_TRUNC when PAGE_SIZE is very large.
  */
  #if PAGE_SIZE < 8192UL
  #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(PAGE_SIZE)
  #else
  #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(8192UL)
  #endif

Link: https://lore.kernel.org/all/20220819200221.422801-2-kuba@kernel.org/
Signed-off-by: Konstantin Shabanov <mail@etehtsea.me>
---
 Documentation/userspace-api/netlink/intro.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst
index aacffade8f84..ca60abe94e3d 100644
--- a/Documentation/userspace-api/netlink/intro.rst
+++ b/Documentation/userspace-api/netlink/intro.rst
@@ -526,8 +526,8 @@ of the recvmsg() system call, *not* a Netlink header).
 
 Upon truncation the remaining part of the message is discarded.
 
-Netlink expects that the user buffer will be at least 8kB or a page
-size of the CPU architecture, whichever is bigger. Particular Netlink
+Netlink expects that the user buffer will be at most 8kB or a page
+size of the CPU architecture, whichever is smaller. Particular Netlink
 families may, however, require a larger buffer. 32kB buffer is recommended
 for most efficient handling of dumps (larger buffer fits more dumped
 objects and therefore fewer recvmsg() calls are needed).

base-commit: 917719c412c48687d4a176965d1fa35320ec457c
-- 
2.53.0

On Tue, 12 May 2026 17:30:53 +0700 Konstantin Shabanov wrote:
> Update the docs to match the code (include/linux/netlink.h):
> 
>   /*
>    *	skb should fit one page. This choice is good for headerless malloc.
>    *	But we should limit to 8K so that userspace does not have to
>    *	use enormous buffer sizes on recvmsg() calls just to avoid
>    *	MSG_TRUNC when PAGE_SIZE is very large.
>   */
>   #if PAGE_SIZE < 8192UL
>   #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(PAGE_SIZE)
>   #else
>   #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(8192UL)
>   #endif

You should explain what you think the problem is in the commit message.
Maybe if you did you'd realize you're comparing kernel header comment
to user space guidance which are (obviously?) the inverse of each
other..

> Link: https://lore.kernel.org/all/20220819200221.422801-2-kuba@kernel.org/

That's not how we refer to committed code.
-- 
pw-bot: reject

On Tue, 12 May 2026 17:27:57 -0700 Jakub Kicinski wrote:
> On Tue, 12 May 2026 17:30:53 +0700 Konstantin Shabanov wrote:
> > Update the docs to match the code (include/linux/netlink.h):
> >
> >   /*
> >    *	skb should fit one page. This choice is good for headerless malloc.
> >    *	But we should limit to 8K so that userspace does not have to
> >    *	use enormous buffer sizes on recvmsg() calls just to avoid
> >    *	MSG_TRUNC when PAGE_SIZE is very large.
> >   */
> >   #if PAGE_SIZE < 8192UL
> >   #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(PAGE_SIZE)
> >   #else
> >   #define NLMSG_GOODSIZE	SKB_WITH_OVERHEAD(8192UL)
> >   #endif
>
> You should explain what you think the problem is in the commit message.
> Maybe if you did you'd realize you're comparing kernel header comment
> to user space guidance which are (obviously?) the inverse of each
> other..

I thought that the comment is self-explaining:

  * But we should limit to 8K so that userspace does not have to
  *	use enormous buffer sizes on recvmsg() calls just to avoid
  *	MSG_TRUNC when PAGE_SIZE is very large.

The problem is that according to the comment, kernel isn't going to send
more than 8K in a single reply and the documentation is currently recommends the opposite:
to create _at least_ 8K buffer what looks excessive.
Also, the logic in the comment is aligned with userspace libraries (libmnl [1]
and wireguard-tools [2]).

[1]: https://git.netfilter.org/libmnl/tree/include/libmnl/libmnl.h?id=54dea548d796653534645c6e3c8577eaf7d77411#n20
[2]: https://git.zx2c4.com/wireguard-tools/tree/src/netlink.h?id=a998407747005ea7e4e0258d96f105c97241e1d3#n70

On Fri, 15 May 2026 22:57:41 +0700 Konstantin Shabanov wrote:
> The problem is that according to the comment, kernel isn't going to send
> more than 8K in a single reply and the documentation is currently recommends the opposite:
> to create _at least_ 8K buffer what looks excessive.

Got it.