From: Takuya Yoshikawa <yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
To: Marcelo Tosatti <mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] KVM: fix the handling of dirty bitmaps to avoid overflows
Date: Tue, 13 Apr 2010 09:52:24 +0900 [thread overview]
Message-ID: <4BC3C048.5030704@oss.ntt.co.jp> (raw)
In-Reply-To: <20100412173951.GA5614-I4X2Mt4zSy4@public.gmane.org>
(2010/04/13 2:39), Marcelo Tosatti wrote:
> On Mon, Apr 12, 2010 at 07:35:35PM +0900, Takuya Yoshikawa wrote:
>> This patch fixes a bug found by Avi during the review process
>> of my dirty bitmap related work.
>>
>> To ppc and ia64 people:
>> The fix is really simple but touches all architectures using
>> dirty bitmaps. So please check this will not suffer your part.
>>
>> ===
>>
>> Int is not long enough to store the size of a dirty bitmap.
>>
>> This patch fixes this problem with the introduction of a wrapper
>> function to calculate the sizes of dirty bitmaps.
>>
>> Note: in mark_page_dirty(), we have to consider the fact that
>> __set_bit() takes the offset as int, not long.
>>
>> Signed-off-by: Takuya Yoshikawa<yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
>
> Applied, thanks.
>
Thanks everyone!
BTW, just from my curiosity, are there any cases in which we use such huge
number of pages currently?
ALIGN(memslot->npages, BITS_PER_LONG) / 8;
More than G pages need really big memory!
-- We are assuming some special cases like "short" int size?
If so, we may have to care about a lot of things from now on, because common
functions like __set_bit() don't support such long buffers.
If not, my patch might be over hacking -- especially the following part:
@@ -1183,10 +1183,13 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
memslot = gfn_to_memslot_unaliased(kvm, gfn);
if (memslot && memslot->dirty_bitmap) {
unsigned long rel_gfn = gfn - memslot->base_gfn;
+ unsigned long *p = memslot->dirty_bitmap +
+ rel_gfn / BITS_PER_LONG;
+ int offset = rel_gfn % BITS_PER_LONG;
/* avoid RMW */
- if (!generic_test_le_bit(rel_gfn, memslot->dirty_bitmap))
- generic___set_le_bit(rel_gfn, memslot->dirty_bitmap);
+ if (!generic_test_le_bit(offset, p))
+ generic___set_le_bit(offset, p);
}
}
next prev parent reply other threads:[~2010-04-13 0:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-12 10:35 [PATCH] KVM: fix the handling of dirty bitmaps to avoid overflows Takuya Yoshikawa
[not found] ` <20100412193535.6c502695.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-12 11:10 ` Alexander Graf
2010-04-12 17:39 ` Marcelo Tosatti
[not found] ` <20100412173951.GA5614-I4X2Mt4zSy4@public.gmane.org>
2010-04-13 0:52 ` Takuya Yoshikawa [this message]
[not found] ` <4BC3C048.5030704-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-13 6:50 ` Avi Kivity
2010-04-13 7:03 ` Takuya Yoshikawa
2010-04-13 7:05 ` Avi Kivity
2010-04-13 13:47 ` [PATCH] KVM: cleanup: limit the number of pages per memory slot Takuya Yoshikawa
2010-04-14 16:58 ` Marcelo Tosatti
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=4BC3C048.5030704@oss.ntt.co.jp \
--to=yoshikawa.takuya-gvgce1chcldl9jvzuh4aog@public.gmane.org \
--cc=avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox