netdev - Re: [PATCH net-next 00/10] net: l3mdev: Support for sockets bound to enslaved device

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:   Tue, 01 Aug 2017 17:41:59 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...il.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 00/10] net: l3mdev: Support for sockets bound
 to enslaved device

From: David Ahern <dsahern@...il.com>
Date: Mon, 31 Jul 2017 20:13:16 -0700

> Existing code for socket lookups already pass in 6+ arguments. Rather
> than add another for the enslaved device index, the existing lookups
> are converted to use a new sk_lookup struct. From there, the enslaved
> device index becomes another element of the struct.

Sorry, not gonna happen :-)

I know it's difficult, but maybe we should think about why we're
passing so much crap into each lookup.

And perhaps, why it can't (for example) be constituted in the lookup
function itself given sufficient (relevant) context.

I think passing a big struct into the lookups, by reference, is a big
step backwards.

For one thing, if you pass it by pointer then the compiler can't
potentially pass parts in registers even if it could.  However
if you pass it by value, that's actually a possibility.

But I'd like to avoid this on-stack blob altogether if possible.

Thanks.