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
| ||
|
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
Powered by blists - more mailing lists