lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87liywl1xv.fsf@rustcorp.com.au>
Date:	Wed, 27 Apr 2011 14:34:44 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Liu Yuan <namei.unix@...il.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver, virtio: Modify the err hanlding logic

On Wed, 20 Apr 2011 21:21:59 +0800, Liu Yuan <namei.unix@...il.com> wrote:
> From: Liu Yuan <tailai.ly@...bao.com>
> 
> In the function vp_request_msix_vectors(), when
> pci_enable_msix() returns 0, there will be
> redundant double checks for 'err'. This patch
> fixes it to avoid the unnecessary check.
> 
> Signed-off-by: Liu Yuan <tailai.ly@...bao.com>
> ---
>  drivers/virtio/virtio_pci.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> index 4fb5b2b..2c05376 100644
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@ -298,10 +298,11 @@ static int vp_request_msix_vectors(struct virtio_device *vdev, int nvectors,
>  
>  	/* pci_enable_msix returns positive if we can't get this many. */
>  	err = pci_enable_msix(vp_dev->pci_dev, vp_dev->msix_entries, nvectors);
> -	if (err > 0)
> -		err = -ENOSPC;
> -	if (err)
> +	if (err) {
> +		if (err > 0)
> +			err = -ENOSPC;
>  		goto error;
> +	}
>  	vp_dev->msix_vectors = nvectors;
>  	vp_dev->msix_enabled = 1;

This patch is extremely marginal.  It theoretically improves efficiency,
but it's in a case we don't care about.  The code is quite clear.

My general policy for such marginal improvements is to only accept them
from the maintainer him/herself, so I won't be taking this patch.

Of course, if you produce a series of fixes to the driver with such a
patch as a cleaner, I'm lazy enough that I'd take them all at once :)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ