netdev - Re: [Xen-devel] [PATCH net-next] xen-netfront: always set num queues if possible

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <55F7FA2D.5040701@citrix.com>
Date:	Tue, 15 Sep 2015 11:59:57 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	"Charles (Chas) Williams" <3chas3@...il.com>,
	<netdev@...r.kernel.org>, <xen-devel@...ts.xenproject.org>
Subject: Re: [Xen-devel] [PATCH net-next] xen-netfront: always set num queues
 if possible

On 14/09/15 22:28, Charles (Chas) Williams wrote:
> The xen store preserves this information across module invocations.
> If you insmod netfront with two queues and later insmod again with one
> queue, the backend will still believe you asked for two queues.

Can you rewrite the commit message to be clearer?

"If netfront connects with 2 (or more) queues and then reconnects with
only 1 queue it fails to delete or rewrite the multi-queue-num-queues
key and netback will try to use the wrong number of queues.

Always write the num-queues field if the backend has multi-queue support."

> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1819,11 +1819,7 @@ again:
>  		goto destroy_ring;
>  	}
>  
> -	if (num_queues == 1) {
> -		err = write_queue_xenstore_keys(&info->queues[0], &xbt, 0); /* flat */
> -		if (err)
> -			goto abort_transaction_no_dev_fatal;
> -	} else {
> +	if (xenbus_exists(xbt, dev->nodename, "multi-queue-num-queues")) {
>  		/* Write the number of queues */
>  		err = xenbus_printf(xbt, dev->nodename, "multi-queue-num-queues",
>  				    "%u", num_queues);

Isn't this broken?  It looks like it won't write the
multi-queue-num-queues key the first time around.

It think this should be conditional on multi-queue-max-queues existing
(which is written by the backend if multi-queue is supported).

David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html