From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Berg Subject: Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type Date: Tue, 05 Dec 2017 17:34:21 +0100 Message-ID: <1512491661.26976.19.camel@sipsolutions.net> References: <20171202202332.10205-1-johannes@sipsolutions.net> <20171205.113145.172521292247335321.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, j@w1.fi, dsahern-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org To: David Miller Return-path: In-Reply-To: <20171205.113145.172521292247335321.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> Sender: linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote: > > > We could try to fix up the big endian problem here, but we > > don't know *how* userspace misbehaved - if using nla_put_u32 > > then we could, but we also found a debug tool (which we'll > > ignore for the purposes of this regression) that was putting > > the padding into the length. > We're stuck with this thing forever... I'd like to consider other > options. > > I've seen this problem at least one time before, therefore I > suggest when we see a U8 attribute with a U32's length: > > 1) We access it as a u32, this takes care of all endianness > issues. Possible, but as I said above, I've seen at least one tool (a debug only script) now that will actually emit a U8 followed by 3 bytes of padding to make it netlink-aligned, but set the length to 4. That would be broken by making this change. I'm not saying this is bad - but there are different levels of compatibility and I'd probably go for "bug compatibility" here rather than "fix-it-up compatibility". Your call, ultimately - I've already fixed the tool I had found :-) > 2) We emit a warning so that the app gets fixes. For sure. johannes