[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Networking for 5.17
On Mon, 10 Jan 2022 19:31:30 -0800 Linus Torvalds wrote:
> > 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.

 \ /
  Last update: 2022-01-11 05:57    [W:0.063 / U:6.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site