11.01.2013 21:03, J. Bruce Fields пишет:
On Fri, Jan 11, 2013 at 06:56:58PM +0400, Stanislav Kinsbursky wrote:
11.12.2012 19:35, J. Bruce Fields пишет:
On Tue, Dec 11, 2012 at 10:20:36AM -0500, J. Bruce Fields wrote:
On Tue, Dec 11, 2012 at 07:07:00PM +0400, Stanislav Kinsbursky wrote:
I don't really understand, how mountd's root can be wrong. I.e.
its' always right as I see it. NFSd kthreads have to swap/use
relative path/whatever to communicate with proper mountd.
Or I'm missing something?
Ugh, I see the problem: I thought svc_export_request was called at the
time mountd does the read, but instead its done at the time nfsd does
the upcall.
I suspect that's wrong, and we really want this done in the context of
the mountd process when it does the read call. If d_path is called
there then we have no problem.
Right, so I'd be happier if we could modify sunrpc_cache_pipe_upcall to
skip calling cache_request and instead delay that until cache_read(). I
think that should be possible.
So, Bruce, what we going to do (or what you want me to do) with the rest of NFSd changes?
I.e. how I should solve this d_path() problem?
I.e. I don't understand what did you mean by "I'd be happier if we could modify sunrpc_cache_pipe_upcall to
skip calling cache_request and instead delay that until cache_read()".
Could you give me a hint?
Definitely. So normally the way these upcalls happen are:
1. the kernel does a cache lookup, finds no matching item, and
calls sunrpc_cache_pipe_upcall().
2. sunrpc_cache_pipe_upcall() formats the upcall: it allocates a
struct cache_request crq and fills crq->buf with the upcall
data by calling the cache's ->cache_request() method.
3. Then rpc.mountd realizes there's data available in
/proc/net/rpc/nfsd.fh/content, so it does a read on that file.
4. cache_read copies the formatted upcall from crq->buf to
to userspace.
So all I'm suggesting is that instead of calling ->cache_request() at
step 2, we do it at step 4.
Then cache_request will be called from rpc.mountd's read. So we'll know
which container rpc.mountd is in.
Does that make sense?
Ok, now I understand.
If the upcall is just the way to inform rpc.mound, that there are some data to read and process, then it your proposing changes should work.
I'll prepare initial patch set.
Thanks!
--b.
--
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
