Re: [Xen-devel] [PATCH v3] xen/arm: alternative: Register re-mapped Xen area as a temporary virtual region

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.17 at 16:23, <julien.grall@xxxxxxx> wrote:
> On 27/03/17 09:40, Wei Chen wrote:
>> @@ -154,8 +155,12 @@ static int __apply_alternatives_multi_stop(void *unused)
>>          int ret;
>>          struct alt_region region;
>>          mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
>> -        unsigned int xen_order = get_order_from_bytes(_end - _start);
>> +        unsigned int xen_size = _end - _start;
> 
> I didn't notice it on the previous reviews. xen_size should technically 
> be paddr_t.
> 
> It is more for consistency than a real bug as the result _end - _start 
> will unlikely ever be > 4GB. I think Stefano should be able to fix on 
> commit. So no need to resend the patch.

Hmm, this mostly addresses one of the two complaints I was going
to make (pushing a patch which didn't go via xen-devel). The other
one remains, though: As indicated before, only security patches
should be pushed to stable branches at about the same time as to
master's staging; everything else should please wait until the patch
has passed the push gate on master. Note, for example, how I've
avoided including the backport of 4edb1a42e3 in the batch I've
just pushed to 4.8-staging, despite this being a very simple and
obvious change.

Jan


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