netdev - Re: Add a SOCK_DESTROY operation to close sockets from userspace

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]

Message-Id: <20151119.113336.1788979303067913870.davem@davemloft.net>
Date:	Thu, 19 Nov 2015 11:33:36 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	zenczykowski@...il.com, lorenzo@...gle.com,
	hannes@...essinduktion.org, stephen@...workplumber.org,
	netdev@...r.kernel.org, edumazet@...gle.com, ek@...gle.com,
	dtor@...gle.com
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Thu, 19 Nov 2015 08:19:24 -0800

> Here is the thing :
> 
> - Android powered phones and devices have a similar code since 2008.
> There is _no_ way they can avoid having this functionality.

Weren't we given similar story about initial wake locks
implementation?  There is no other way, Android does this forever,
we have to have this!

> Every-time I make a change in linux TCP stack, this code breaks, and
> this a  real pain because Android changes need to be carried over to
> vendors.

I'm very glad that you felt the pain enough that you finally had
to reluctantly try and upstream something.  I'm sorry that doing
hackish things locally in the Android kernel tree is so painful :-/

Android folks really do not care about upstream, and it is probably
bottom of their priority.  Their actions consistently support this.

Now I am supposed to urgently care about some of their problems.

What kind of relationship is this?  It sounds quite one sided if you
ask me.

> We have a clear business case here, and I would like we find a solution.

I'm sorry, I thought the plan was to stay on 3.10 kernel in Android
forever, that putting upstream issues as far down the road as
possible.

> Having this code in upstream kernel will save me time and energy to deal
> with real issues and improvements, not with bugs opened by Android
> engineers 9 months after I did changes in upstream kernels.

I think the timeline is more like 2+ years.

Guess what, it's frustrating for me too!

> [2] Taking air time to send keepalive(s) and receive their answers is
> going to make all radio providers shout really loud. They are already
> installing stupid proxies filtering/compressing ACK messages and
> breaking TCP clocking.

I understand.

But you know what, if you just toss some major facility like this onto
the list you have to expect some discussion, disagreement, and
suggestions of alternate schemes.

Some of which you may not like nor consider appropriate at all.

You have been considering this non-stop for whatever time you have
been working on this, everyone else is now considering and thinking
about this for the first time right now.

Therefore you must be understanding and patient.  Just like I've been
patiently waiting for my Nexus 6 to be updated to something newer than
2+ year old kernel technology.

You cannot just say "I signoff on this, it's the only reasonable
scheme, apply it."  That's not how we do things here.

Frankly, that kind of attitude makes me want to apply this series even
less, and encourage attempts to find alternate schemes even more.

Thanks.
--
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