All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: David Ahern <dsahern@kernel.org>,
	davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com, Ilya Maximets <i.maximets@ovn.org>,
	donald.hunter@gmail.com
Subject: Re: [PATCH net] inet: bring NLM_DONE out to a separate recv() again
Date: Fri, 12 Apr 2024 19:22:00 +0200	[thread overview]
Message-ID: <20240412192200.662d92ae@elisabeth> (raw)
In-Reply-To: <20240411140154.2acd3d0a@kernel.org>

On Thu, 11 Apr 2024 14:01:54 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Thu, 11 Apr 2024 13:45:42 -0600 David Ahern wrote:
> > > +	/* Don't let NLM_DONE coalesce into a message, even if it could.
> > > +	 * Some user space expects NLM_DONE in a separate recv().    
> > 
> > that's unfortunate  
> 
> Do you have an opinion on the sysfs/opt-in question?
> Feels to me like there shouldn't be that much user space doing raw
> netlink, without a library. Old crufty code usually does ioctls, right?

I think so too -- if there were more (maintained) applications with
this issue, we would have noticed by now.

> So maybe we can periodically reintroduce this bug to shake out all 
> the bad apps? :D

Actually, I had half a mind of proposing something on these lines: add
a TODO comment here and revisit in, say, two years.

I guess it's definitely more painful for libreswan, but for passt, I
think it's quite unlikely that distribution users could get the
"breaking" kernel change without a fixed version of the application: we
made a new release relatively close to the NLM_DONE change.

There might be substantial value in keeping this type of short netlink
exchanges fast, for example for container engines that need to be able
to spawn a bazillion containers per second.

-- 
Stefano


  parent reply	other threads:[~2024-04-12 17:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11 18:02 [PATCH net] inet: bring NLM_DONE out to a separate recv() again Jakub Kicinski
2024-04-11 18:42 ` Eric Dumazet
2024-04-11 18:57   ` Jakub Kicinski
2024-04-11 19:35 ` Ilya Maximets
2024-06-17 15:09   ` Ilya Maximets
2024-06-17 16:36     ` Jakub Kicinski
2024-06-17 17:05       ` Ilya Maximets
2024-04-11 19:45 ` David Ahern
2024-04-11 21:01   ` Jakub Kicinski
2024-04-11 21:14     ` David Ahern
2024-04-12 17:22     ` Stefano Brivio [this message]
2024-04-12 17:38       ` Ilya Maximets
2024-04-12 18:03         ` Stefano Brivio
2024-04-12 18:22           ` Ilya Maximets
2024-04-15  9:30 ` patchwork-bot+netdevbpf

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=20240412192200.662d92ae@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=i.maximets@ovn.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@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 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.