Re: [PATCH libnetfilter_queue v3 1/1] src: Add nfq_nlmsg_put2() - user specifies header flags

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sat, Nov 18, 2023 at 03:11:56PM +1100, Duncan Roe wrote:
> Hi Pablo,
> 
> Can we please sort out just what you want before I send nfq_nlmsg_put2 v4?
> 
> And, where applicable, would you like the same changes made to nfq_nlmsg_put?

Just send a v4 with the changes I request for this patch, then once
applied, you can follow up to update nfq_nlmsg_put() in a separated
patch to amend that description too.

So, please, only one patch series at a time.

> On Wed, Nov 15, 2023 at 12:41:03PM +0100, Pablo Neira Ayuso wrote:
[...]
> > > + * attempt to configure NFQA_CFG_F_SECCTX on a system not runnine SELinux.
> > > + * \n
> > > + * NLM_F_ACK instructs the kernel to send a message in response
> > > + * to a successful command.
> >
> > As I said above, this is not accurate.
> > > + * The kernel always sends a message in response to a failed command.
>
> I dispute that my description was inaccurate, but admit it could be clearer,
> maybe if I change the order and elaborate a bit.
> propose
>
> > > + * The kernel always sends a message in response to a failed command.
> > > + * NLM_F_ACK instructs the kernel to also send a message in response
> > > + * to a successful command.

LGTM, however:

> > > + * This ensures a following read() will not block.

Remove this sentence, because the blocking behaviour you observe is
because !NLM_F_ACK and no failure means no message is sent, and if
your application is there to recv(), it will wait forever because
kernel will send nothing.