Re: [PATCH kvm-unit-tests 17/18] arm: do not allocate virtio buffers from the stack

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

 



On Tue, Oct 24, 2017 at 05:21:44PM +0200, Paolo Bonzini wrote:
> The stack will be in virtual memory space starting from the next patch,
> so the address of automatic variables will not be a physical address
> anymore.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> ---
>  lib/chr-testdev.c | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/chr-testdev.c b/lib/chr-testdev.c
> index c19424f..ca4a10b 100644
> --- a/lib/chr-testdev.c
> +++ b/lib/chr-testdev.c
> @@ -30,20 +30,19 @@ static void __testdev_send(char *buf, unsigned int len)
>  void chr_testdev_exit(int code)
>  {
>  	unsigned int len;
> -	char buf[8];
> -
> -	snprintf(buf, sizeof(buf), "%dq", code);
> -	len = strlen(buf);
> +	static char buf[8];
>  
>  	spin_lock(&lock);
>  
> -	if (!vcon)
> -		goto out;
> +	snprintf(buf, sizeof(buf), "%dq", code);
> +	len = strlen(buf);
>  
> -	__testdev_send(buf, len);
> +	if (vcon) {
> +		__testdev_send(buf, len);
> +		printf("this shouldn't have happened!");
> +	}
>  
> -out:
> -	spin_unlock(&lock);
> +	while (1);

I'd rather we continue to exit gracefully from chr_testdev_exit(),
allowing callers to unconditionally call it, and then do their own
"shouldn't have happened" printing, or fallback to another way to
exit. That way when a unit test is run without the chr-testdev
provided, exit() can still work, just differently. Granted we only
have halt() for that fallback right now, but I've exploited the fact
that chr_testdev_exit() will just return, without the chr-testdev
device present, several times in temporary hacks.

Thanks,
drew


>  }
>  
>  void chr_testdev_init(void)
> -- 
> 2.14.2
> 
> 



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux