netdev - Re: [GIT PULL] Networking for 5.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220110205603.6bc9b680@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Mon, 10 Jan 2022 20:56:03 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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.