From: Avi Kivity <avi@redhat.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [PATCH v2 04/16] KVM: MMU: return bool in __rmap_write_protect
Date: Mon, 16 Apr 2012 17:28:32 +0300 [thread overview]
Message-ID: <4F8C2C90.6030703@redhat.com> (raw)
In-Reply-To: <20120416231455.f978b3ac9fb995cfce2853ae@gmail.com>
On 04/16/2012 05:14 PM, Takuya Yoshikawa wrote:
> On Sun, 15 Apr 2012 14:25:30 +0300
> Avi Kivity <avi@redhat.com> wrote:
>
> > > > @@ -1689,7 +1690,7 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu,
> > > >
> > > > kvm_mmu_pages_init(parent, &parents, &pages);
> > > > while (mmu_unsync_walk(parent, &pages)) {
> > > > - int protected = 0;
> > > > + bool protected = false;
> > > >
> > > > for_each_sp(pages, sp, parents, i)
> > > > protected |= rmap_write_protect(vcpu->kvm, sp->gfn);
> > >
> > > Isn't this the reason we prefer int to bool?
> > >
> > > Not sure people like to use |= with boolean.
> > >
> >
> > Why not?
> >
>
> The code "bitwise OR assignment" is assuming the internal representations
> of true and false: true=1, false=0.
No, it doesn't. |= converts the result back to bool.
In fact it's better than
int x;
...
x |= some_value() & MASK;
since MASK might be of type longer than int, and the result can be
truncated. With bool |=, it cannot.
Disassembly of section .text:
0000000000000000 <f>:
static bool x;
void f(long y)
{
x |= y;
0: 0f b6 05 00 00 00 00 movzbl 0x0(%rip),%eax # 7 <f+0x7>
3: R_X86_64_PC32 .bss-0x4
7: 48 09 c7 or %rax,%rdi
a: 0f 95 05 00 00 00 00 setne 0x0(%rip) # 11 <f+0x11>
d: R_X86_64_PC32 .bss-0x4
}
11: c3 retq
The corresponding code with 'int x' would just store the truncated
result back into x.
> I might have seen some point if it had been
> protected = protected || rmap_...
>
>
> But the real question is whether there is any point in re-writing completely
> correct C code: there are tons of int like this in the kernel code.
>
> __rmap_write_protect() was introduced recently, so if this conversion is
> really worthwhile, I should have been told to use bool at that time, no?
It's up to developer and maintainer preference. I like bool since it
documents the usage and is safer, but sometimes I miss it on review.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-04-16 14:28 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 10:05 [PATCH v2 00/16] KVM: MMU: fast page fault Xiao Guangrong
2012-04-13 10:09 ` [PATCH v2 01/16] KVM: MMU: cleanup __direct_map Xiao Guangrong
2012-04-13 10:10 ` [PATCH v2 02/16] KVM: MMU: introduce mmu_spte_establish Xiao Guangrong
2012-04-13 10:10 ` [PATCH v2 03/16] KVM: MMU: properly assert spte on rmap walking path Xiao Guangrong
2012-04-14 2:15 ` Takuya Yoshikawa
2012-04-16 3:26 ` Xiao Guangrong
2012-04-13 10:11 ` [PATCH v2 04/16] KVM: MMU: return bool in __rmap_write_protect Xiao Guangrong
2012-04-14 2:00 ` Takuya Yoshikawa
2012-04-15 11:25 ` Avi Kivity
2012-04-16 14:14 ` Takuya Yoshikawa
2012-04-16 14:28 ` Avi Kivity [this message]
2012-04-16 15:54 ` Takuya Yoshikawa
2012-04-13 10:11 ` [PATCH v2 05/16] KVM: MMU: abstract spte write-protect Xiao Guangrong
2012-04-14 2:26 ` Takuya Yoshikawa
2012-04-16 3:27 ` Xiao Guangrong
2012-04-13 10:12 ` [PATCH v2 06/16] KVM: VMX: export PFEC.P bit on ept Xiao Guangrong
2012-04-13 10:12 ` [PATCH v2 07/16] KVM: MMU: introduce for_each_pte_list_spte Xiao Guangrong
2012-04-14 2:44 ` Takuya Yoshikawa
2012-04-16 3:36 ` Xiao Guangrong
2012-04-17 14:47 ` Takuya Yoshikawa
2012-04-18 4:01 ` Xiao Guangrong
2012-04-21 1:01 ` Takuya Yoshikawa
2012-04-21 4:36 ` Xiao Guangrong
2012-04-18 10:03 ` Xiao Guangrong
2012-04-21 1:03 ` Takuya Yoshikawa
2012-04-13 10:13 ` [PATCH v2 08/16] KVM: MMU: store more bits in rmap Xiao Guangrong
2012-04-13 10:13 ` [PATCH v2 09/16] KVM: MMU: fast mmu_need_write_protect path for hard mmu Xiao Guangrong
2012-04-13 10:14 ` [PATCH v2 10/16] KVM: MMU: fask check whether page is writable Xiao Guangrong
2012-04-14 3:01 ` Takuya Yoshikawa
2012-04-16 3:38 ` Xiao Guangrong
2012-04-15 15:16 ` Avi Kivity
2012-04-16 3:25 ` Xiao Guangrong
2012-04-16 10:02 ` Avi Kivity
2012-04-16 10:20 ` Xiao Guangrong
2012-04-16 11:47 ` Avi Kivity
2012-04-17 3:55 ` Xiao Guangrong
2012-04-17 7:41 ` Avi Kivity
2012-04-17 12:10 ` Xiao Guangrong
2012-04-13 10:14 ` [PATCH v2 11/16] KVM: MMU: introduce SPTE_ALLOW_WRITE bit Xiao Guangrong
2012-04-13 10:15 ` [PATCH v2 12/16] KVM: MMU: introduce SPTE_WRITE_PROTECT bit Xiao Guangrong
2012-04-13 10:15 ` [PATCH v2 13/16] KVM: MMU: break sptes write-protect if gfn is writable Xiao Guangrong
2012-04-13 10:16 ` [PATCH v2 14/16] KVM: MMU: fast path of handling guest page fault Xiao Guangrong
2012-04-18 1:47 ` Marcelo Tosatti
2012-04-18 3:53 ` Xiao Guangrong
2012-04-18 23:08 ` Marcelo Tosatti
2012-04-13 10:17 ` [PATCH v2 15/16] KVM: MMU: trace fast " Xiao Guangrong
2012-04-13 10:17 ` [PATCH v2 16/16] KVM: MMU: fix kvm_mmu_pagetable_walk tracepoint Xiao Guangrong
2012-04-14 3:37 ` [PATCH v2 00/16] KVM: MMU: fast page fault Takuya Yoshikawa
2012-04-16 3:50 ` Xiao Guangrong
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=4F8C2C90.6030703@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=takuya.yoshikawa@gmail.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox