Netdev List
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Ricardo Robaina <rrobaina@redhat.com>,
	audit@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, paul@paul-moore.com, eparis@redhat.com,
	edumazet@google.com, pabeni@redhat.com, horms@kernel.org
Subject: Re: [PATCH v2] netlink, audit: prevent false ENOBUFS on timeout expiry
Date: Thu, 28 May 2026 16:29:01 -0700	[thread overview]
Message-ID: <20260528162901.2d68e2e0@kernel.org> (raw)
In-Reply-To: <2143396.Jadu78ljVU@x2>

On Thu, 28 May 2026 18:40:44 -0400 Steve Grubb wrote:
> > > (3) A new NETLINK_F_RECV_NO_ENOBUFS socket flag doesn't exist in stable
> > > kernels where this bug is actively impacting users  
> > 
> > Which commit are you referring to? Isn't that flag itself ancient?  
> 
> You're right, it is. I see how this flag would fix the pathological behavior 
> that was reported. But as I have looked at this suggestion, there seems to be 
> one wrinkle. User space should not need to know that the audit code in the 
> kernel has this retry mechanism. 

It's not about the retry mechanism, at least in my mind - I read 
your reply as "user space should not know that there was congestion".
Why? It's not very useful, I get that, but user space can just clear
the congestion signal and keep going.

> It seems like the audit subsystem should set the flag on auditd's
> socket at registration time in auditd_set(). The kernel is the right
> place for this because it's the kernel that manages the retry/ hold
> queues and sets the sk_sndtimeo that triggers the overrun path -
> auditd has no knowledge of these internals.

We have to carry this code somewhere, either in user space or in 
the kernel. I'd prefer not to carry it in the kernel.

      reply	other threads:[~2026-05-28 23:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 17:24 [PATCH v2] netlink, audit: prevent false ENOBUFS on timeout expiry Ricardo Robaina
2026-05-18 11:03 ` Simon Horman
2026-05-27 19:26   ` Ricardo Robaina
2026-05-19  0:35 ` Jakub Kicinski
2026-05-26 20:53   ` Paul Moore
2026-05-27 19:34     ` Ricardo Robaina
2026-05-27 19:29   ` Ricardo Robaina
2026-05-27 22:29     ` Jakub Kicinski
2026-05-28 22:40       ` Steve Grubb
2026-05-28 23:29         ` Jakub Kicinski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260528162901.2d68e2e0@kernel.org \
    --to=kuba@kernel.org \
    --cc=audit@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=eparis@redhat.com \
    --cc=horms@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=rrobaina@redhat.com \
    --cc=sgrubb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox