On Tue, Mar 04, 2014 at 01:17:50PM -0800, Linus Torvalds wrote: > On Tue, Mar 4, 2014 at 12:00 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > > > > OK, with the attached set (the first one is essentially unchanged from > > your first one), it seems to work and produce better code on all targets > > I've tried. Comments? > > I'm certainly ok with it. You seem to have left the fput_light() > function around, though, despite removing fget_[raw_]light(). That > seems a bit silly, since there is no valid use any more apart from > net/socket.c that now doesn't balance things properly.
There's also a pile of crap around sockfd_lookup/sockfd_put, related to that. Moreover, there's net/compat.c, which probably ought to have the compat syscalls themselves moved to net/socket.c (under ifdef CONFIG_COMPAT) and switched to sockfd_lookup_light(). There's l2tp_tunnel_sock_lookup(), which is simply broken - it assumes that if tunnel->fd still resolves to a socket, that socket must be l2tp one. Trivial to drive into BUG_ON(), in queue_work() callback, no less... There's bluetooth, assuming that pretty much the same (that if it got a file descriptor that resolves to a socket, it must be a bluetooth one). BTW, I wonder what will happen if one gives iscsi_sw_tcp_conn_bind() descriptor of a socket of sufficiently weird sort... Then there's staging/usbip with its sockfd_to_socket(), which is more or less parallel to sockfd_lookup(). And open-coded analogs in nbd and ncpfs... > > I've also pushed those (on top of old ocfs2 fix) into vfs.git#for-linus, > > if you prefer to read it that way. Should propagate in a few... > > Should I pull? > > I also get the feeling that the first patch should likely be marked > for stable. Hmm? It should; I'll mark it such when I send a pull request. I really want to sort the situation with sockfd_lookup() and friends out, though - at least to the point where I would understand how painful the fixes will be. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
