All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/3] xen: rework paging_log_dirty_op to work with hvm guests
Date: Wed, 6 May 2015 14:32:42 +0200	[thread overview]
Message-ID: <554A09EA.3060706@citrix.com> (raw)
In-Reply-To: <554A20BB02000078000771E4@mail.emea.novell.com>

El 06/05/15 a les 14.10, Jan Beulich ha escrit:
>>>> On 06.05.15 at 13:55, <roger.pau@citrix.com> wrote:
>> El 14/04/15 a les 14.14, Jan Beulich ha escrit:
>>>>>> On 10.04.15 at 19:29, <roger.pau@citrix.com> wrote:
>>>> +                    BUG_ON(((pages >> 3) % PAGE_SIZE) + bytes > PAGE_SIZE);
>>>
>>> I don't seem to be able to spot the original for this one. If there
>>> was none, please make this an ASSERT() instead.
>>
>> Yes, there's no previous BUG_ON because this was not a problem in the
>> past, since we could write to any position on dirty_bitmap, but that's
>> not the case any more. Since we only have one page mapped at a time we
>> need to make sure that what we are about to write doesn't cross a page
>> boundary.
>>
>> I understand this is not an ideal solution, but AFAICT there's no easy
>> way to deal with writes that expand over a page boundary.
> 
> I'm afraid I don't really see what you're asking for. Just to clarify -
> I didn't put anything under question, all I asked for was to use
> ASSERT() instead of BUG_ON() here. Yet what you wrote above
> doesn't seem to related to that request.

I don't think an ASSERT is appropriate here, because it means that on
non-debug versions we might write past the end of the mapped page
without noticing.

Roger.

  reply	other threads:[~2015-05-06 12:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 17:29 [PATCH v3 0/3] xen/pvh: enable migration on PVH Dom0 Roger Pau Monne
2015-04-10 17:29 ` [PATCH v3 1/3] xen/pvh: enable mmu_update hypercall Roger Pau Monne
2015-04-14 11:55   ` Jan Beulich
2015-04-14 12:03     ` Roger Pau Monné
2015-04-14 13:10       ` Andrew Cooper
2015-04-16  9:04         ` Tim Deegan
2015-04-10 17:29 ` [PATCH v3 2/3] xen/shadow: fix shadow_track_dirty_vram to work on hvm guests Roger Pau Monne
2015-04-14 12:22   ` Jan Beulich
2015-05-06 15:12     ` Roger Pau Monné
2015-05-06 15:41       ` Jan Beulich
2015-04-10 17:29 ` [PATCH v3 3/3] xen: rework paging_log_dirty_op to work with " Roger Pau Monne
2015-04-11  9:27   ` Roger Pau Monné
2015-04-14 12:14   ` Jan Beulich
2015-04-16  9:11     ` Tim Deegan
2015-04-16  9:49       ` Jan Beulich
2015-05-06 11:55     ` Roger Pau Monné
2015-05-06 12:10       ` Jan Beulich
2015-05-06 12:32         ` Roger Pau Monné [this message]
2015-05-06 12:39           ` Jan Beulich

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=554A09EA.3060706@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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.