Messages in this thread | | | Date | Mon, 10 Jan 2022 20:56:03 -0800 | From | Jakub Kicinski <> | Subject | Re: [GIT PULL] Networking for 5.17 |
| |
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.
| |