On 22.05.2012 19:18, Simo Sorce wrote:
On Tue, 2012-05-22 at 19:10 +0400, Stanislav Kinsbursky wrote:
On 22.05.2012 18:58, Simo Sorce wrote:
On Tue, 2012-05-22 at 17:32 +0400, Stanislav Kinsbursky wrote:
It actually means, that no hard-coded init_net references should appear - and
that's all. Required network context have to be taken from currently existent
objects (like RPC client, RPC service, etc) and, if not available (it's very
rare case - like NFS mount call), from current->nsproxy->net_ns.
You don't need to do anything special except this.
There will be a problem with your patches in container, because you are using
unix socket. But this problem is not in your patches but in unix sockets
themselves. So don't worry about it.
Can you tell me if the attached patches are all you think is needed ?
If they are, I'll squash them in with other fixes and will send out a
new patch set.
Yep, looks good.
Would be great, if you'll fix a couple of minor issues:
1) rename "xprt_net" to "net" in prototypes (just to make things look in one
style with other places in SUNRPC layer)
TBH, I thikn using 'net' is the worst name you guys could come up with,
try to 'git grep net' to see what I mean, but whatever, the damage is
already done, I'll change it.
The reason for the simple name was that we don't care, where we gained this net:
was it transport or whatever.
IOW, "xprt_net" doesn't carrying any required information comparing to "net" in
this case.
2) define net variable on stack in svcauth_gss_proxy_init() (looks simpler):
+static int svcauth_gss_proxy_init(struct svc_rqst *rqstp,
+ struct rpc_gss_wire_cred *gc, __be32 *authp)
....
+ struct net *net = rqstp->rq_xprt->xpt_net;
+ struct sunrpc_net *sn = net_generic(net, sunrpc_net_id);
....
+ status = gssp_accept_sec_context_upcall(net,&ud);
Heh, that is what I did at first, then changed. Works for me, I'll
include these changes in the new patchset.
Thanks, Simo.
Simo.
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
