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]

Date:   Mon, 10 Jan 2022 19:31:30 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jakub Kicinski <kuba@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>
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 Sun, Jan 9, 2022 at 6:52 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> At the time of writing we have one known conflict (/build failure)
> with tip, Stephen's resolution looks good:

Ok, the trees that trigger the conflict haven't actually hit my tree
yet, so I'll see that particular conflict later.

I assume I'll get the irq_set_affinity_and_hint() patches from Thomas
at some point - Thomas, can  you make sure to remind me of this
conflict, because this is exactly the kind of thing I would catch on
my home machine due to doing full builds, but that I will probably
miss if I'm on the road.

I'm home for a couple more days and will try to do as much of the
merge window heavy lifting as possible before my travels start, but
we'll see..

>   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.

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.

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...

               Linus