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? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
