Message ID | 20240906154517.191976-1-pbonzini@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] KVM fixes for Linux 6.11-rc7 | expand |
The pull request you sent on Fri, 6 Sep 2024 11:45:17 -0400:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d45111e52b81e0da6307bde9de8f2a5ac72d9ca9
Thank you!
On Fri, 6 Sept 2024 at 08:45, Paolo Bonzini <pbonzini@redhat.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. 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. Linus
On Fri, Sep 06, 2024 at 03:38:16PM -0700, Linus Torvalds wrote: > On Fri, 6 Sept 2024 at 08:45, Paolo Bonzini <pbonzini@redhat.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
On Fri, 6 Sept 2024 at 16:40, Nathan Chancellor <nathan@kernel.org> wrote: > > 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 Their argument seems to be "the missing fallthrough has no effect". Which is true. But they seem to be missing that it has no effect *NOW*. One major problem case is that people tend to add new cases to the end of a switch() statement, not counting that final "default: break". So the "it doesn't have any effect NOW" is true, but the next time somebody edits that and doesn't check warnings, it *will* have very strange behavior, and it won't be affecting the newly added case, but some entirely unrelated previous case. So I really think the lack of warnings is a gcc mis-feature. It leaves code in a bad situation going forward. Oh well. Many times I have had to disable warnings entirely because they have too many false positives, so I guess the occasional "doesn't warn enough" is still a better problem to have. And at least we have (a) clang warning about it and (b) require the warnings going forward and use -Werror, so at least for the kernel the "when somebody edits that code, you get surprising behavior" case _will_ get noticed. Linus