From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> Date: Fri, 7 Apr 2017 21:35:50 +0200 > On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote: > [...] >> Let's just discuss the UAPI, since people complain we don't talk >> about that enough :-) For those playing at home it is three new >> attributes returned in a netlink ACK when the application asks >> for the extended response: >> >> NLMSGERR_ATTR_MSG string Extended error string >> NLMSGERR_ATTR_OFFS u32 Byte offset to netlink element causing error >> NLMSGERR_ATTR_CODE u32 Subsystem specific error code >> NLMSGERR_ATTR_ATTR u16 Netlink attribute triggering error or missing > > I think it would be good if we get a definition to cap the maximum > string length to something reasonable? This can be added in a follow > up patch BTW. Thus, we get people coming back to us and request larger > strings with a reason why they need more room for this. > > In general, my main concern with strings is that they can be used in a > more freely way than these u32 offsets and error codes, and > specifically how inconsistent these string will look like across > different netlink subsystems. > > Anyway, as long as this is optional (not every subsystem if forced to > use strings) I'm fine with it :). I have no strong opinions about string length. In my opinion, I would like to believe that if someone tried to get a networking patch applied that emitted a rediculously long string then we would give them feedback about how that is not acceptable. Right? I suspect that someone will eventually give us a hard time about the strings wrt. internationalization. :-) It's solvable at least partially in userspace I suppose.
