lkml.org 
[lkml]   [2008]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared
    Date
    On Sep 9, 2008, at Sep 9, 2008, 2:20 PM, ebiederm@xmission.com wrote:
    > Chuck Lever <chuck.lever@oracle.com> writes:
    >
    >> If the upper layers are responsible for providing the utsname, you
    >> will need to
    >> fix up lockd and the NFS server's callback client too, at least.
    >
    > Actually looking at the code. It looks like a proper fix may be
    > even simpler.
    > Why do we have both clnt->cl_server and clnt->cl_nodename? Or is
    > cl_server
    > the other side of the connection?

    cl_server is the server-side. cl_nodename is the "machine name" of
    the client.

    >>>> What are we trying to achieve by reading utsname?
    >>>
    >>> It looks like it gets copied into the sunrpc messages so I assume
    >>> it is
    >>> a part of the sunrpc spec?
    >>
    >> It appears to be used only for RPC's AUTH_SYS credentials. The
    >> nodename is used
    >> to identify the caller's host. See RFC 1831, Appendix A:
    >>
    >> http://rfclibrary.hosting.com/rfc/rfc1831/rfc1831-16.asp
    >
    > Thanks that helps a lot.
    >
    >> I'm not terribly familiar with uts namespaces, though. Can someone
    >> explain why
    >> we need to distinguish between these for AUTH_SYS if the caller is
    >> on a remote
    >> system?
    >
    > Semantically processes in different uts namespaces are on different
    > machines.

    OK.

    >> I don't like the idea of an oops in here. Instead, (for now) it
    >> should warn and
    >> fail to create the client, IMO.
    >
    > Which is interesting when the problem happens during NFS unmount.
    > Although
    > frankly it could fail anyway.
    >
    > It seems strange that we are creating a client during unmount anyway.

    It's worth investigating. Just enable RPC tracing (/usr/sbin/rpcdebug
    -m rpc -s all) before shutting down the client.

    NFS unmounting is historically difficult because during a system
    shutdown, unmounting is the last thing to occur, and usually happens
    after most system services (such as the portmapper service) have
    become unavailable. That's fine for local file systems, but it makes
    for a rather dodgy situation for NFS.

    --
    Chuck Lever
    chuck[dot]lever[at]oracle[dot]com


    \
     
     \ /
      Last update: 2008-09-09 21:17    [W:4.819 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site