netdev - Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

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

Date:	Wed, 25 Nov 2015 11:38:14 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:	netdev@...r.kernel.org, Tom Herbert <tom@...bertland.com>,
	Florian Westphal <fw@...len.de>, davem@...emloft.net
Subject: Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hi,

On Tue, Nov 24, 2015, at 23:21, Alexei Starovoitov wrote:
> On Tue, Nov 24, 2015 at 10:58:08PM +0100, Hannes Frederic Sowa wrote:
> > > > > 
> > > > > interesting idea, but then remote host will be influencing local cpu
> > > > > selection?
> > > > > how remote can figure out the number of local cpus?
> > > > 
> > > > Via rpc! :)
> > > > 
> > > > The configuration shouldn't change all the time and some get_info rpc
> > > > call could provide info for the topology of the machine, or...
> > > 
> > > Configuration changes all the time. Machines crash, traffic redirected
> > > because of load, etc, etc
> > 
> > Yeah, same problem you have to handle with the kcm approach.
> 
> not at all. No new remote configuration things are needed.

At some point you have to manage your ip address and if you move a host
subnet or an ip address it should not matter a lot.

> > Just use GRO engine and TCP PSH flag, maybe by making it more
> > intentional via user space APIs on one connection. Wake up thread with
> > one complete RPC message. If receiver eats more data it is no problem,
> > if less, it will block as in your approach, too. Your worker threads
> > must handle that anyway and can buffer and concatenate it to the next
> > message to be processed.
> 
> of course not. kcm reading threads don't have to deal with it.

If there is no fallback for this you have to drop frames and kill the
TCP connection for all your RPC endpoints. If you lost synchronization
with the headers there is no way you will resync. 

> PS
> just noticed that you've excluded all. By accident?
> Feel free to reply to all.

Oh, thanks, yes it was a fault on my side.

For full transparency I reply.

Bye,
Hannes
--
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