All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: RE: [PATCH][v2] KVM: x86/mmu: fix counting of rmap entries in pte_list_add
Date: Sat, 26 Sep 2020 06:34:13 +0000	[thread overview]
Message-ID: <83a9d7fe8a364083974571ff51a809ca@baidu.com> (raw)
In-Reply-To: <20200925164332.GA31528@linux.intel.com>



> -----Original Message-----
> From: Sean Christopherson [mailto:sean.j.christopherson@intel.com]
> Sent: Saturday, September 26, 2020 12:44 AM
> To: Li,Rongqing <lirongqing@baidu.com>
> Cc: kvm@vger.kernel.org; x86@kernel.org
> Subject: Re: [PATCH][v2] KVM: x86/mmu: fix counting of rmap entries in
> pte_list_add
> 
> On Wed, Sep 23, 2020 at 12:58:58PM +0800, Li RongQing wrote:
> > counting of rmap entries was missed when desc->sptes is full and
> > desc->more is NULL
> >
> > and merging two PTE_LIST_EXT-1 check as one, to avoids the extra
> > comparison to give slightly optimization
> 
> Please write complete sentences, and use proper capitalization and
> punctuation.
> It's not a big deal for short changelogs, but it's crucial for readability of larger
> changelogs.
> 
> E.g.
> 
>   Fix an off-by-one style bug in pte_list_add() where it failed to account
>   the last full set of SPTEs, i.e. when desc->sptes is full and desc->more
>   is NULL.
> 
>   Merge the two "PTE_LIST_EXT-1" checks as part of the fix to avoid an
>   extra comparison.
> 
> > Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> No need to give me credit, I just nitpicked the code, identifying the bug and the
> fix was all you. :-)
> 
> Thanks for the fix!
> 
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> 
> Paolo,
> 
> Although it's a bug fix, I don't think this needs a Fixes / Cc:stable.  The bug
> only results in rmap recycling being delayed by one rmap.  Stable kernels can
> probably live with an off-by-one bug given that RMAP_RECYCLE_THRESHOLD is
> completely arbitrary. :-)
> 
> Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
> 

Thank you very much , I will send V3

-Li

      reply	other threads:[~2020-09-26  6:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23  4:58 [PATCH][v2] KVM: x86/mmu: fix counting of rmap entries in pte_list_add Li RongQing
2020-09-25 16:43 ` Sean Christopherson
2020-09-26  6:34   ` Li,Rongqing [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a9d7fe8a364083974571ff51a809ca@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=kvm@vger.kernel.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.