the mystery that is sock_fasync

[David Miller <davem@davemloft.net>]

I was studying sock_fasync() and it definitely has a bunch
of questionable issues.

Well firstly, it duplicates fasync_helper() entirely.
The only difference is that sock_fasync() does socket
local locking which is better for performance.  fasync_helper()
uses a global spinlock to protect the fasync list it is given.

Secondly, and I think more importantly, this thing acts as
if it is possible to have more than one file --> socket
mapping.  That is simply impossible.

There can indeed be many file descriptors that point to the
file object that points to the socket inode, but that's
different.

This invariant is maintained by the fact that socket
creations creates and maps one file object to point
to the socket's inode in sock_create.

Furthermore we block any attempt to open sockets by name
via things like /proc/$PID/fds/$sock_fdnum

In fact when sock_close() runs, it calls sock_fasync(-1, file, 0) and
the subsequent sock_release() bug checks that fasync_list is NULL.

If my analysis is correct we can incredibly simplify sock_fasync().

Did I miss some way that multiple file objects can point to the
same socket inode?