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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 31 Mar 2017, Jan Beulich wrote:
> >>> 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).

I noticed the comment only after I pushed the commit. Given how trivial
it is, I fixed it in a separate commit.


> 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.

Yes, you are right, this is important. I admit that it is the second
time that I fall into this easy mistake. Of course I ran some tests on
the backport, but I still should have waited for the push-gate. Given
that the vast majority of the backports are security fixes, which are
pushed straight way to several trees, it is easy to forget I shouldn't
do that for non-security fixes. I'll get better. But I wonder, as stable
trees maintainer, do you have a specific git configuration or a script
that helps you avoid this kind of mistakes? Or is it all by hand?

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