linux-kernel - Re: [PATCH REBASED] KVM: x86: SVM: Fix one redefine issue about VMCB_AVIC_APIC_BAR

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:   Thu, 6 Apr 2023 10:21:20 +0800
From:   Xinghui Li <korantwork@...il.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com,
        mlevitsk@...hat.com, linux-kernel@...r.kernel.org, x86@...nel.org,
        kvm@...r.kernel.org, Xinghui Li <korantli@...cent.com>
Subject: Re: [PATCH REBASED] KVM: x86: SVM: Fix one redefine issue about VMCB_AVIC_APIC_BAR_MASK

On Wed, Apr 5, 2023 at 7:44 AM Sean Christopherson <seanjc@...gle.com> wrote:
>
> On Mon, 03 Apr 2023 17:52:00 +0800, korantwork@...il.com wrote:
> > VMCB_AVIC_APIC_BAR_MASK is defined twice with the same value in svm.h,
> > which is meaningless. Delete the duplicate one.
>
> Applied to kvm-x86 svm, thanks!
>
> In the future, please don't use "PATCH REBASED".  If you're sending a new
> version of a patch that's been rebased, then the revision number needs to be
> bumped.  The fact that the only change is that the patch was rebased isn't
> relevant as far as versioning is concerned, it's still a new version.  The
> cover letter and/or ignored part of the patch is where the delta between
> versions should be captured.
>
> And in this case, there really was no need to send a new version, the original
> patch still applies cleanly.  I suspect that the REBASED version was sent as a
> form of a ping, which again is not the right way to ping a patch/series.  If you
> want to ping, please reply to the original patch.  Unnecessarily sending new
> versions means more patches to sort through, i.e. makes maintainers lives harder,
> not easier.
>
Firstly, I'm so so SORRY to burden you in this way.
I found the last patch can't be am directly, so I send a new patch
with the last rebased code.
I used to believe that this would alleviate your burden, but
unfortunately, it had the opposite effect.
Again, sorry for my wrong operation.

Thanks~