On 4/10/17 9:30 AM, Johannes Berg wrote: > On Mon, 2017-04-10 at 09:26 -0600, David Ahern wrote: >> On 4/8/17 2:24 PM, Johannes Berg wrote: >>> @@ -2300,14 +2332,35 @@ void netlink_ack(struct sk_buff *in_skb, >>> struct nlmsghdr *nlh, int err) >>> NLMSG_ERROR, payload, 0); >>> errmsg = nlmsg_data(rep); >>> errmsg->error = err; >>> - memcpy(&errmsg->msg, nlh, payload > sizeof(*errmsg) ? nlh- >>>> nlmsg_len : sizeof(*nlh)); >>> + memcpy(&errmsg->msg, nlh, >>> + !(nlk->flags & NETLINK_F_CAP_ACK) ? nlh->nlmsg_len >>> + : sizeof(*nlh)); >>> + >> >> generically this makes userspace parsing more problematic: the >> parsing layer may not know if the socket option has been set to >> precisely know the size of errmsg->msg and how much data needs to be >> skipped to get to the new attributes. > > Yes, I know. I'd hope that userspace can remember that per socket - I > don't see a good other way to do this. > > If we insert the TLVs in front of, or instead of (with a TLV containing > it), the request message then at least libnl's debugging will need to > be changed. > > As it is, I can assume that libnl will not set the CAP setting, and > everything works fine even if I don't change libnl, which makes things > easier. > > Do you have any better ideas? NETLINK_F_CAP_ACK and NETLINK_F_EXT_ACK should be incompatible -- if one is set the other can not be set. CAP_ACK means abbreviate the response and EXT_ACK means give me more data.
