netdev - RE: [PATCH net] xen-netback: bookkeep number of queues in our own module

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jun 2014 09:30:52 +0000
From:	Paul Durrant <Paul.Durrant@...rix.com>
To:	David Miller <davem@...emloft.net>
CC:	Wei Liu <wei.liu2@...rix.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
	Ian Campbell <Ian.Campbell@...rix.com>
Subject: RE: [PATCH net] xen-netback: bookkeep number of queues in our own
 module

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: 23 June 2014 10:26
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@...ts.xen.org; netdev@...r.kernel.org;
> boris.ostrovsky@...cle.com; Ian Campbell
> Subject: Re: [PATCH net] xen-netback: bookkeep number of queues in our
> own module
> 
> From: Paul Durrant <Paul.Durrant@...rix.com>
> Date: Mon, 23 Jun 2014 09:18:23 +0000
> 
> > Ok, for the addition of a new algorithm that may be the case but
> > what about the existent algorithm stability issue? Who's going to
> > watch the implementation of __netdev_pick_tx() and make sure there
> > is no semantic change? I'm still of the opinion that the
> > implementation should be kept within netback so that we can
> > guarantee stability, even if it means duplication. Either that or we
> > need some guarantee that the semantic of __netdev_pick_tx() will
> > never change.
> 
> Please stop talking like this.
> 
> If the default changes it's probably to fix a bug or make things
> better, you want no bugs to get fix if it breaks "stability"?

To some extent, yes. My hypothesis is that the frontend and the backend agree a steering algorithm so that they can ensure all rx and tx traffic for a flow hits a particular CPU, so that locking can be avoided. If the backend then changes its algorithm then packets may arrive on the wrong queue, hit the wrong CPU and now you have a frontend that may try to access critical data structures without locking from two different CPUs. That's going to be a pretty subtle crash to have to debug.

  Paul
--
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