[RFC] SIOCGSTAMP semantics

[Al Viro <viro@ZenIV.linux.org.uk>]

	ioctl() in question
1) fails with EOPNOTSUPP on
	AF_ALG, AF_CAIF, AF_IUCV, AF_KEY, AF_NFC, AF_RXRPC, AF_VSOCK
2) fails with ENOTTY on
	AF_DECnet, AF_KCM, AF_LLC, AF_NETLINK, AF_PHONET, AF_PPPOX, AF_RDS,
	AF_TIPC, AF_UNIX
3) fails with EINVAL on
	AF_ISDN
4) sock_get_timestamp(sock->sk, arg)
	AF_INET, AF_INET6, AF_CAN, AF_ROSE, AF_PACKET, AF_IEEE802154,
	AF_ATMSVC, AF_ATMPVC, AF_APPLETALK
5) sock_get_timestamp(sock->sk, arg) under lock_sock(sock->sk)
	AF_AX25, AF_NETROM, AF_QRTR, AF_IPX
6) sock_get_timestamp(sock->sk, arg) after checking that sock->sk != NULL
	AF_X25, AF_IRDA

AF_BLUETOOTH is sometimes (1), sometimes (2), sometimes (4).  Not sure about
AF_SMC - sometimes it's (1), sometimes might be (4).

To make the things even less consistent, AF_CAN, AF_IPX and AF_QRTR lack
SIOCGSTAMPNS; everything else has it parallel to SIOCGSTAMP with s/timestamp/&ns/.

Am I right assuming that (5) and (6) should be like (4)?  IOW, that
lock_sock() is not needed for anyone and that sock->sk cannot be NULL on
anything that could be fed to ioctl()?  If the last assumption is not true,
we have a plenty of triggerable oopsen - other ioctls (handled on the top
level) do _not_ check that and dereference sock->sk directly.  I've grepped
around, and AFAICS NULL sock->sk on an opened socket should be impossible,
but confirmation would be nice.

Another question, of course, is whether anyone gives a damn about distinctions
between (1), (2) and (3) *and* if anything bad would've happenend from having
sock_get_timestamp() simply done to all sockets, right in net/socket.c.

Comments?