linux-kernel - Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

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: <20240906233958.GA1968981@thelio-3990X>
Date: Fri, 6 Sep 2024 16:39:58 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [GIT PULL] KVM fixes for Linux 6.11-rc7

On Fri, Sep 06, 2024 at 03:38:16PM -0700, Linus Torvalds wrote:
> On Fri, 6 Sept 2024 at 08:45, Paolo Bonzini <pbonzini@...hat.com> wrote:
> >
> > - Specialize return value of KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM),
> >   based on VM type
> 
> Grr. This actually causes a build warning with clang, but I didn't
> notice in my "between pulls" build check, because that is with gcc.
> 
> So now it's merged with this error:
> 
>    arch/x86/kvm/x86.c:4819:2: error: unannotated fall-through between
> switch labels [-Werror,-Wimplicit-fallthrough]
> 
> and I'm actually surprised that gcc didn't warn about this too.

Yeah, GCC does not warn when falling through to a break or return, as I
mention in the patch I sent for this (I was going to keep an eye out for
the pull request and comment before it went in but looks like I missed
it):

https://lore.kernel.org/kvm/20240905-kvm-x86-avoid-clang-implicit-fallthrough-v1-1-f2e785f1aa45@kernel.org/

> We definitely enable -Wimplicit-fallthrough on gcc too, but apparently
> it's not functional: falling through to a "break" statement seems to
> not warn with gcc. Which is nonsensical, but whatever.

This was brought up to GCC at one point and they considered its current
behavior as working as intended from my understanding:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432

Cheers,
Nathan