Re: [PATCH] xen: x86_32: do not enable iterrupts when returning fromexception in interrupt context

[Jeremy Fitzhardinge]

On 08/31/2011 04:47 PM, Igor Mammedov wrote:
> If vmalloc page_fault happens inside of interrupt handler with interrupts
> disabled then on exit path from exception handler when there is no pending
> interrupts, the following code (arch/x86/xen/xen-asm_32.S:112):
>
> 	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> 	sete XEN_vcpu_info_mask(%eax)
>
> will enable interrupts even if they has been previously disabled according to
> eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99)
>
> 	testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp)
> 	setz XEN_vcpu_info_mask(%eax)
>
> Solution is in setting XEN_vcpu_info_mask only when it should be set
> according to
> 	cmpw $0x0001, XEN_vcpu_info_pending(%eax)
> but not clearing it if there isn't any pending events.

Wow, that's a great find.  I guess it shows how rarely we end up doing
an exception return with interrupts disabled, since that's been there
since, erm, 2.6.23?

But this could definitely explain some bugs where interrupts became
unexpectedly re-enabled.  Were you tracking one down when you found this?

> Signed-off-by: Igor Mammedov <imammedo@xxxxxxxxxx>
> ---
>  arch/x86/xen/xen-asm_32.S |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/xen/xen-asm_32.S b/arch/x86/xen/xen-asm_32.S
> index 22a2093..313dca7 100644
> --- a/arch/x86/xen/xen-asm_32.S
> +++ b/arch/x86/xen/xen-asm_32.S
> @@ -113,10 +113,14 @@ xen_iret_start_crit:
>  
>  	/*
>  	 * If there's something pending, mask events again so we can
> -	 * jump back into xen_hypervisor_callback
> +	 * jump back into xen_hypervisor_callback. Otherwise do not
> +	 * touch XEN_vcpu_info_mask.
>  	 */
> +	jne ignore_vcpu_info_mask
>  	sete XEN_vcpu_info_mask(%eax)
>  
> +ignore_vcpu_info_mask:
> +

This should be:

	jne 1f
	movb $1, XEN_vcpu_info_mask(%eax)

1:	popl %eax 


There's no point in using sete if we're already using a conditional jump
to avoid the write, and it's better to use local labels for little
control flow changes like this.

Thanks,
    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/