netdev - Re: [PATCH net-next v4 4/4] netfilter: nfnetlink: Handle ACK flags for batch messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240422133328.3d626130@kernel.org>
Date: Mon, 22 Apr 2024 13:33:28 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Donald Hunter <donald.hunter@...il.com>, netdev@...r.kernel.org, "David
 S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo
 Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>, Jacob Keller
 <jacob.e.keller@...el.com>, Jozsef Kadlecsik <kadlec@...filter.org>,
 netfilter-devel@...r.kernel.org, coreteam@...filter.org,
 donald.hunter@...hat.com
Subject: Re: [PATCH net-next v4 4/4] netfilter: nfnetlink: Handle ACK flags
 for batch messages

On Thu, 18 Apr 2024 09:51:53 -0700 Jakub Kicinski wrote:
> On Thu, 18 Apr 2024 18:30:55 +0200 Pablo Neira Ayuso wrote:
> > Out of curiosity: Why does the tool need an explicit ack for each
> > command? As mentioned above, this consumes a lot netlink bandwidth.  
> 
> I think that the tool is sort of besides the point, it's just a PoC.
> The point is that we're trying to describe netlink protocols in machine
> readable fashion. Which in turn makes it possible to write netlink
> binding generators in any language, like modern RPC frameworks.
> For that to work we need protocol basics to be followed.
> 
> That's not to say that we're going to force all netlink families to
> change to follow extra new rules. Just those that want to be accessed
> via the bindings.

Pablo, any thoughts? Convinced? Given this touches YNL in significant
ways I'd prefer to merge it to net-next.