Re: [Xen-devel] [PATCH 01/12] xen/events: refactor retrigger_dynirq() and resend_irq_on_evtchn()

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Aug 09, 2013 at 07:15:10PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
> 
> These two function did the same thing with different parameters, put
> the common bits in retrigger_evtchn().
> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
>  drivers/xen/events.c |   27 +++++++++------------------
>  1 files changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index a58ac43..1697cf2 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1529,13 +1529,13 @@ static int set_affinity_irq(struct irq_data *data, 
> const struct cpumask *dest,
>       return rebind_irq_to_cpu(data->irq, tcpu);
>  }
>  
> -int resend_irq_on_evtchn(unsigned int irq)
> +static int retrigger_evtchn(int evtchn)
>  {
> -     int masked, evtchn = evtchn_from_irq(irq);
> +     int masked;
>       struct shared_info *s = HYPERVISOR_shared_info;
>  
>       if (!VALID_EVTCHN(evtchn))
> -             return 1;
> +             return 0;
>  

This looks weird. Either resend_irq_on_evtchn is bogus in first place or
resend_irq_on_evtchn is different from retrigger_dynirq.

Looking at Linus's tree I tend to believe the first case.

If it is the first case I think it deserves a separate patch and
backport to stable.


Wei.

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