On Thu, Nov 30, 2023, Like Xu wrote: > On 26/10/2023 9:10 am, Sean Christopherson wrote: > > On Wed, Oct 25, 2023, Sean Christopherson wrote: > > > On Wed, Oct 25, 2023, Like Xu wrote: > > > > Emm, did we miss this little fix ? > > > > > > No, I have it earmarked, it's just not a priority because it doesn't truly fix > > > anything. Though I suppose it probably makes to apply it for 6.8, waiting one > > > more day to send PULL requests to Paolo isn't a problem. > > > > Heh, when I tried to apply this I got reminded of why I held it for later. I > > want to apply it to kvm-x86/misc, but that's based on ~6.6-rc2 (plus a few KVM > > patches), i.e. doesn't have the "buggy" commit. I don't want to rebase "misc", > > nor do I want to create a branch and PULL request for a single trivial commit. > > > > So for logistical reasons, I'm not going apply this right away, but I will make > > sure it gets into v6.7. > > Thanks, and a similar pattern occurs with these functions: > > 'write_register_operand' > 'account_shadowed' > 'unaccount_shadowed' > 'mtrr_lookup_fixed_next' > 'pre_svm_run' > 'svm_vcpu_deliver_sipi_vector' > > Although the compiler will do the right thing, use 'return void' expression > deliberately without grounds for exemption may annoy some CI pipelines. > > If you need more cleanup or a new version to cover all these cases above, > just let me know. I'd rather update the CI pipelines to turn off -Wpedantic. There is zero chance that -Wpedantic will ever get enabled for kernel builds, the kernel is deliberately not ISO C compliant. I have no objection to cleaning up kvm_vcpu_ioctl_x86_get_xsave() because it's an obvious goof and a recent change, but like checkpatch warnings, I don't want to go around "fixing" warnings unless they are actively problematic for humans.
