You are viewing landley

Tired of ads? Upgrade to paid account and never see ads again!
The Conversation Pit - NFS, NFS, NFS... [entries|archive|friends|userinfo]
Rob Landley

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

NFS, NFS, NFS... [Feb. 20th, 2011|11:39 pm]
Rob Landley
[mood |determineddetermined]

Sigh. My big breakthrough with NFS wasn't tracking down everything what needed to be fixed, but finally managing to narrow down a test case to the point where I could get a very artificial test to perform correctly with only three changes. (And all three changes were the same trick, which probably isn't the _right_ trick form a merging standpoint, but accomplish the same thing in a much less intrusive way: replace init_net with current->nsproxy->net_ns because the code is always executed in a specific user context from which the correct network context can be harvested and cached.) There are still three instances of init_net in fs/nfs but they're all nfsv4 and I don't have to care about them just yet. (Good thing too: they're "callbacks", from who knows where, I have no idea _what_ process context (if any) they get called in...)

I'm still not _quite_ sure about that "always", but I'm not sure how much of this is NFS specific. (What happens if you do "mount -o remount,rw" from a different network context...) This is the realm of follow-up patches, but I still have to care to make it reliable.

And there are eight more instances of init_net in net/sunrpc (and three false positives), and I'm still laboriously grinding my way through that crap to figure out what context each one is called in and where it should be getting its data from. But I don't think any of those are actually the problem I'm seeing, I think the problem is that it's matching cached RPC entries by address without also comparing network namespace.

Oh, my CIFS patch wasn't actually an init_net instance replacement, it was fixing the implicit init_net buried inside the sock_create_kern() function. I've been asked for a follow-up patch there to make kerberos work, but haven't got a kerberos test environment set up yet, and have yet to find where the darn kerberos code _is_. Probably the CIFS_UPCALL stuff... which is spawning a userspace /sbin/request-key binary as a child of the host's PID 1... And in the DNS resolver:

saved_cred = override_creds(dns_resolver_cache);
rkey = request_key(&key_type_dns_resolver, desc, options);

Yeah, that's not going to work... where is override_creds() defined?

The war continues...