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.
