I couldn't _quite_ get the patch to be size neutral when CONFIG_NET_FS was disabled, because switching from sock_create_kern() to __sock_create() added 16 bytes each (two extra arguments to the function call, on a 64 bit host), and did so in two functions (the ipv6 function is a block copied version of the ipv4 one, I may detour into trying to splice those two back together as a general cleanup). Plus some presumably unrelated function grew 2 bytes for no apparent reason (alignment padding?), although with all the inlining going on it's hard to definitively say "unrelated" about anything. But it's reasonably close to size neutral.
I need to go back to staring at NFS again. I'm _supposed_ to be fixing that one, but honestly I still can't wrap my head around how the darn thing works, and can't think of a shorter way of gaining such an understanding than reading the v2 and v3 RFCs beginning to end in order (which is slow going, RFCs are dense and dry), _and_ reading all the NFS source (over a megabyte thereof).
The cifs protocol is horrible but I know what I can ignore there. NFS is a giant series of layering violations, RPC, cacheing, and "upcalls", and the bits I'm interested in differ between v2, v3, and v4...
I also got my unrelated net debug cleanup patch reposted with thunderbird behaving itself, and posted a documentation update to thunderbird. The temptation to do more unrelated patches that AREN'T NFS is kind of strong, but I expected that.