[Cake] NLA_F_NESTED is missing

[Dean Scarff]

 On Mon, 02 Nov 2020 13:37:00 +0100, Toke wrote:
> Dean Scarff <dos at scarff.id.au> writes:
>
>>  Hi,
>>
>>  I've been happily running the out-of-tree sch_cake on my Raspberry 
>> Pi
>>  since 2015.  However, I recently upgraded my kernel (to 5.4.72 from
>>  Raspbian's raspberrypi-kernel 1.20201022-1), which comes with the
>>  sch_cake in mainline.  Now, when running:
>>
>>    sudo /sbin/tc qdisc add dev ppp0 root cake
>>
>>  I get the error:
>>
>>    Error: NLA_F_NESTED is missing.
>>
>>  I get this error with the sch_cake in mainline, and also with 
>> sch_cake
>>  built out-of-tree.  I also get the error with both Debian's 
>> iproute2
>>  5.9.0-1 (built myself via debian/rules) and "tc" from dtaht's 
>> tc-adv
>>  repo.
>>
>>  Any ideas on what this error means and how to fix it?
>
> I just tried building a 5.4.72 kernel and couldn't reproduce this, so 
> it
> seems it's a fault with the raspberry pi kernel; I guess opening a 
> bug
> against that would be the way to go?
>
> As for what's actually causing this, I couldn't find anything obvious
> that touches this code in the qdisc layer; but I suppose it has
> something to do with the core qdisc netlink parsing code?
>
> -Toke

 Thanks for the data point.

 For the record, the relevant kernel source is:
 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/net/netlink.h?h=v5.4.72#n1143
 and the Pi branch:
 https://github.com/raspberrypi/linux/blob/raspberrypi-kernel_1.20201022-1/include/net/netlink.h#L1143

 It seems very unlikely that the Pi folks are patching the netlink 
 stuff, so I don't think I'll get much traction there unless I can call 
 out something specifically wrong with their patchset.

 My current theory (despite the 4 combinations I tried) is that there's 
 some mismatch between Raspbian/Debian's tc and the kernel (somewhere in 
 the tc's qdisc code it's calling nla_parse_nested but not setting 
 nla_type), but it's odd that nobody else can repro.  tbh the Debian 
 patches look pretty innocent too:

 https://salsa.debian.org/debian/iproute2/-/tree/558bae88bd0befc1bf3e1070733bafd522e44992/debian/patches

 I should be able to figure it out by poking around in tc with gdb.