From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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.
