Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT

[Denis Kenzior <denkenz@gmail.com>]

Hi Johannes,

On 12/05/2016 09:14 AM, Johannes Berg wrote:
>>> Well, no, that'd only work with an open connection :)
>
> Actually, it also works fairly easily for when firmware has 4-way-
> handshake offload, which will be coming to a kernel near you soon.
>

Great, but still not applicable for all devices, and still questionable 
how useful an unmanaged connection actually is.  But okay.

>> And even that is questionable in my mind for some of the more
>> advanced cases.
>
> Well, at least in that case you can have things running (for a while)
> if the manager crashes?
>

To what purpose?  That's like saying that maybe a socket should be kept 
open in case an application crashes.

>> But I'm not sure what your point is, do you still have objections to
>> this approach?
>
> Well, first of all, you can keep things running, at least until you've
> figured out how to restart wpa_supplicant/whatever.
>
> There also aren't really any important resources to clear when
> userspace dies, at least nothing that userspace can't trivially clear
> later by disconnecting (even unconditionally and ignoring the
> result)...

Sure, but in the meantime you have a completely unmanaged connection, 
with no connection manager to tell you what the state of it is.  Maybe 
okay for a command line system with a brain in front of it, but not much 
use anywhere else.

But for that use case the SOCKET_OWNER attribute can be omitted...

>
> So basically I just don't see the advantage. It feels like trading a
> single line of userspace code to disconnect with some (not super
> complex, but still somewhat involved) kernel-side tracking. That
> doesn't really seem like a worthwhile tradeoff to me.
>

Well, we'd be trading quite a bit of race-prone user space code that 
performs the clean up on start up for one line of attributes.  I call 
that a good trade.

Also, I thought it was good form / the UNIX way to clean up after 
processes exit ungracefully.  You seem to be arguing against that?  I 
would argue the kernel should be doing the opposite.  It should always 
clean up the connection unless user space has indicated it can be 'reused'.

Regards,
-Denis