Re: [PATCH v3 1/5] netlink: extended ACK reporting

[David Miller <davem@davemloft.net>]

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 11 Apr 2017 19:31:43 +0200

> On Tue, Apr 11, 2017 at 08:25:57AM -0600, David Ahern wrote:
>> On 4/11/17 1:02 AM, Johannes Berg wrote:
>> > On Tue, 2017-04-11 at 08:59 +0200, Pablo Neira Ayuso wrote:
>> >> CAP_ACK means: trim off the payload that the netlink error message
>> >> is embedding, just like ICMP error does.
>> >>
>> >> What is exactly your concern? If the user explicitly requests this
>> >> via socket option for this socket, then we're expecting they do the
>> >> right handling for what they're asking for.
>> > 
>> > I think David's concern was that when you want to parse the ACK in a
>> > library (or application), you may not easily know if the application
>> > (or library) requested capping.
>> 
>> exactly.
> 
> Then, the library needs to be extended to enable this handling to
> modify the way it needs to handle errors, together with the
> setsockopt().

That's my take on this.

If there are libraries where there is a disconnect between the thing
that controls the sending of the netlink request from the processing
of the netlink response, that really is their problem to work out.

If they wish to support extended ACK reports, they will need to
sort those details out.

If there is sharing of a newlink socket between different libraries,
each wanting to operate in a different mode, that isn't all that
reasonable to me.  Often libraries can't even agree on whether they
want to use a socket fd in non-blocking vs. blocking mode.

David, if you have a specific case where it's absolutely impossible
to resolve this when the library is converted to support extended
ACKs, please mention it.

Thanks.