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: Fri, 3 Aug 2018 00:08:05 +0300 From: "Michael S. Tsirkin" <mst@...hat.com> To: "Nambiar, Amritha" <amritha.nambiar@...el.com> Cc: Andrei Vagin <avagin@...tuozzo.com>, netdev@...r.kernel.org, davem@...emloft.net, alexander.h.duyck@...el.com, willemdebruijn.kernel@...il.com, sridhar.samudrala@...el.com, alexander.duyck@...il.com, edumazet@...gle.com, hannes@...essinduktion.org, tom@...bertland.com, tom@...ntonium.net, jasowang@...hat.com, gaowanlong@...fujitsu.com, virtualization@...ts.linux-foundation.org, rostedt@...dmis.org Subject: Re: [net-next, v6, 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue On Thu, Aug 02, 2018 at 02:04:12PM -0700, Nambiar, Amritha wrote: > On 8/1/2018 5:11 PM, Andrei Vagin wrote: > > On Tue, Jul 10, 2018 at 07:28:49PM -0700, Nambiar, Amritha wrote: > >> With this patch series, I introduced static_key for XPS maps > >> (xps_needed), so static_key_slow_inc() is used to switch branches. The > >> definition of static_key_slow_inc() has cpus_read_lock in place. In the > >> virtio_net driver, XPS queues are initialized after setting the > >> queue:cpu affinity in virtnet_set_affinity() which is already protected > >> within cpus_read_lock. Hence, the warning here trying to acquire > >> cpus_read_lock when it is already held. > >> > >> A quick fix for this would be to just extract netif_set_xps_queue() out > >> of the lock by simply wrapping it with another put/get_online_cpus > >> (unlock right before and hold lock right after). > > > > virtnet_set_affinity() is called from virtnet_cpu_online(), which is > > called under cpus_read_lock too. > > > > It looks like now we can't call netif_set_xps_queue() from cpu hotplug > > callbacks. > > > > I can suggest a very straightforward fix for this problem. The patch is > > attached. > > > > Thanks for looking into this. I was thinking of fixing this in the > virtio_net driver by moving the XPS initialization (and have a new > get_affinity utility) in the ndo_open (so it is together with other tx > preparation) instead of probe. Your patch solves this in general for > setting up cpu hotplug callbacks which is under cpus_read_lock. I like this too. Could you repost in a standard way (inline, with your signoff etc) so we can ack this for net-next? > >> But this may not a > >> clean solution. It'd help if I can get suggestions on what would be a > >> clean option to fix this without extensively changing the code in > >> virtio_net. Is it mandatory to protect the affinitization with > >> read_lock? I don't see similar lock in other drivers while setting the > >> affinity. I understand this warning should go away, but isn't it safe to > >> have multiple readers. > >> > >>> On Fri, Jun 29, 2018 at 09:27:07PM -0700, Amritha Nambiar wrote:
Powered by blists - more mailing lists