Date:   Mon, 10 Jan 2022 20:56:03 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     David Miller <davem@davemloft.net>,
        Netdev <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Networking for 5.17
Message-ID: <20220110205603.6bc9b680@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
In-Reply-To: <CAHk-=wg-pW=bRuRUvhGmm0DgqZ45A0KaH85V5KkVoxGKX170Xg@mail.gmail.com>
References: <20220110025203.2545903-1-kuba@kernel.org>
        <CAHk-=wg-pW=bRuRUvhGmm0DgqZ45A0KaH85V5KkVoxGKX170Xg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.