[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 3/3] xen: rework paging_log_dirty_op to work with hvm guests



>>> On 06.05.15 at 14:32, <roger.pau@xxxxxxxxxx> wrote:
> El 06/05/15 a les 14.10, Jan Beulich ha escrit:
>>>>> On 06.05.15 at 13:55, <roger.pau@xxxxxxxxxx> wrote:
>>> El 14/04/15 a les 14.14, Jan Beulich ha escrit:
>>>>>>> On 10.04.15 at 19:29, <roger.pau@xxxxxxxxxx> 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.

With that argumentation there shouldn't be any ASSERT()s, but only
BUG_ON()s.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.