Re: [GIT PULL] Networking for 5.17

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 10 Jan 2022 19:31:30 -0800 Linus Torvalds wrote:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git tags/5.17-net-next  
> 
> Merged. But I now note that this actually triggers an error when
> building with clang:
> 
>   net/netfilter/nf_tables_api.c:8278:4: error: variable 'data_size' is
> uninitialized when used here [-Werror,-Wuninitialized]
>                           data_size += sizeof(*prule) + rule->dlen;
>                           ^~~~~~~~~
> 
> and I think clang is entirely right.
> 
> Sadly, I didn't actually notice that before having done the merge, so
> I'll have to do the fixup as a separate commit.

Damn it :/ Sorry.
 
> I really wish we had more automation doing clang builds. Yes, some
> parts of the kernel are still broken with clang, but a lot isn't, and
> this isn't the first time my clang build setup has found issues.

We have clang W=1 running on patchwork but the PR this came thru didn't
register right. I'll build test with clang going forward.

> I also notice that NET_VENDOR_VERTEXCOM defaults to 'n'. That's fine
> by me, but it seems unusual. Normally the 'enable vendor XYZ' tend to
> default to 'y'. But for unusual (and new) vendors, maybe that 'n' is
> the right thing to avoid unnecessary questions.
> 
> And maybe that NET_VENDOR_xyz thing has happened many times before,
> and I just haven't happened to notice...

There is a patch posted to flip it back to 'y' already, I didn't think
it was worth waiting for. That said I don't actually know why vendors
default to y. The only explanation I can come up with it's that it was
done so that people running olddefconfig right after the per-vendor
split was introduced wouldn't lose all drivers. We'll fix vertexcom
for consistency but may flip all the vendors' default to 'n' for 
the next merge window.