25 Oct, 2011

5 commits


19 Oct, 2011

1 commit


13 Jul, 2011

1 commit

  • Because struct rpcbind_args *map was declared static, if two
    threads entered this method at the same time, the values
    assigned to map could be sent two two differen tasks.
    This could cause all sorts of problems, include use-after-free
    and double-free of memory.

    Fix this by removing the static declaration so that the map
    pointer is on the stack.

    Signed-off-by: Ben Greear
    Cc: stable@kernel.org
    Signed-off-by: Trond Myklebust

    Ben Greear
     

28 May, 2011

1 commit

  • As libtirpc does in user space, have our registration API try using an
    AF_LOCAL transport first when registering and unregistering.

    This means we don't chew up privileged ports, and our registration is
    bound to an "owner" (the effective uid of the process on the sending
    end of the transport). Only that "owner" may unregister the service.

    The kernel could probe rpcbind via an rpcbind query to determine
    whether rpcbind has an AF_LOCAL service. For simplicity, we use the
    same technique that libtirpc uses: simply fail over to network
    loopback if creating an AF_LOCAL transport to the well-known rpcbind
    service socket fails.

    This means we open-code the pathname of the rpcbind socket in the
    kernel. For now we have to do that anyway because the kernel's
    RPC over AF_LOCAL implementation does not support autobind. That may
    be undesirable in the long term.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

17 Dec, 2010

4 commits

  • Now that all client-side XDR decoder routines use xdr_streams, there
    should be no need to support the legacy calling sequence [rpc_rqst *,
    __be32 *, RPC res *] anywhere. We can construct an xdr_stream in the
    generic RPC code, instead of in each decoder function.

    This is a refactoring change. It should not cause different behavior.

    Signed-off-by: Chuck Lever
    Tested-by: J. Bruce Fields
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Now that all client-side XDR encoder routines use xdr_streams, there
    should be no need to support the legacy calling sequence [rpc_rqst *,
    __be32 *, RPC arg *] anywhere. We can construct an xdr_stream in the
    generic RPC code, instead of in each encoder function.

    Also, all the client-side encoder functions return 0 now, making a
    return value superfluous. Take this opportunity to convert them to
    return void instead.

    This is a refactoring change. It should not cause different behavior.

    Signed-off-by: Chuck Lever
    Tested-by: J. Bruce Fields
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Clean up.

    Just fixed a panic where the nrprocs field in a different upper layer
    client was set by hand incorrectly. Use the compiler-generated method
    used by the other upper layer protocols.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Clean up.

    The trend in the other XDR encoder functions is to BUG() when encoding
    problems occur, since a problem here is always due to a local coding
    error. Then, instead of a status, zero is unconditionally returned.

    Update the rpcbind XDR encoders to behave this way.

    To finish the update, use the new-style be32_to_cpup() and
    cpu_to_be32() macros, and compute the buffer sizes using raw integers
    instead of sizeof(). This matches the conventions used in other XDR
    functions.

    Signed-off-by: Chuck Lever
    Tested-by: J. Bruce Fields
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

27 Oct, 2010

1 commit

  • * 'for-2.6.37' of git://linux-nfs.org/~bfields/linux: (99 commits)
    svcrpc: svc_tcp_sendto XPT_DEAD check is redundant
    svcrpc: no need for XPT_DEAD check in svc_xprt_enqueue
    svcrpc: assume svc_delete_xprt() called only once
    svcrpc: never clear XPT_BUSY on dead xprt
    nfsd4: fix connection allocation in sequence()
    nfsd4: only require krb5 principal for NFSv4.0 callbacks
    nfsd4: move minorversion to client
    nfsd4: delay session removal till free_client
    nfsd4: separate callback change and callback probe
    nfsd4: callback program number is per-session
    nfsd4: track backchannel connections
    nfsd4: confirm only on succesful create_session
    nfsd4: make backchannel sequence number per-session
    nfsd4: use client pointer to backchannel session
    nfsd4: move callback setup into session init code
    nfsd4: don't cache seq_misordered replies
    SUNRPC: Properly initialize sock_xprt.srcaddr in all cases
    SUNRPC: Use conventional switch statement when reclassifying sockets
    sunrpc/xprtrdma: clean up workqueue usage
    sunrpc: Turn list_for_each-s into the ..._entry-s
    ...

    Fix up trivial conflicts (two different deprecation notices added in
    separate branches) in Documentation/feature-removal-schedule.txt

    Linus Torvalds
     

19 Oct, 2010

1 commit

  • > The reason for this is in the future, we may want to support additional
    > address family types. We should, therefore, ensure that every piece of
    > code that is sensitive to address families fail in some orderly manner
    > to let developers know where a change is needed.

    Makes sense. I was under impression, that AF-s other than INET are not
    cared about at all :(

    Here's a fixed version of the patch.

    Log:

    Its callers check for ERR_PTR.

    Signed-off-by: Pavel Emelyanov
    Reviewed-by: Chuck Lever
    Signed-off-by: J. Bruce Fields

    Pavel Emelyanov
     

02 Oct, 2010

1 commit


22 Sep, 2010

1 commit


17 Sep, 2010

1 commit


25 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

04 Dec, 2009

4 commits

  • Autobinding is handled by the rpciod process, not in user processes
    that are generating regular RPC requests. Thus autobinding is usually
    not affected by signals targetting user processes, such as KILL or
    timer expiration events.

    In addition, an RPC request generated by a user process that has
    RPC_TASK_SOFTCONN set and needs to perform an autobind will hang if
    the remote rpcbind service is not available.

    For rpcbind queries on connection-oriented transports, let's use the
    new soft connect semantic to return control to the user's process
    quickly, if the kernel's rpcbind client can't connect to the remote
    rpcbind service.

    Logic is introduced in call_bind_status() to handle connection errors
    that occurred during an asynchronous rpcbind query. The logic
    abandons the rpcbind query if the RPC request has SOFTCONN set, and
    retries after a few seconds in the normal case.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Use TCP with the soft connect semantic for local rpcbind upcalls so
    the kernel can detect immediately if the local rpcbind daemon is not
    running.

    Signed-off-by: Chuck Lever

    Chuck Lever
     
  • The kernel's rpcbind client creates and deletes an rpc_clnt and its
    underlying transport socket for every upcall to the local rpcbind
    daemon.

    When starting a typical NFS server on IPv4 and IPv6, the NFS service
    itself does three upcalls (one per version) times two upcalls (one
    per transport) times two upcalls (one per address family), making 12,
    plus another one for the initial call to unregister previous NFS
    services. Starting the NLM service adds an additional 13 upcalls,
    for similar reasons.

    (Currently the NFS service doesn't start IPv6 listeners, but it will
    soon enough).

    Instead, let's create an rpc_clnt for rpcbind upcalls during the
    first local rpcbind query, and cache it. This saves the overhead of
    creating and destroying an rpc_clnt and a socket for every upcall.

    The new logic also prevents the kernel from attempting an RPCB_SET or
    RPCB_UNSET if it knows from the start that the local portmapper does
    not support rpcbind protocol version 4. This will cut down on the
    number of rpcbind upcalls in legacy environments.

    Signed-off-by: Chuck Lever

    Chuck Lever
     
  • Clean up: At one point, rpcb_local_clnt() handled IPv6 loopback
    addresses too, but it doesn't any more; only IPv4 loopback is used
    now. Get rid of the @addr and @addrlen arguments to
    rpcb_local_clnt().

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

10 Aug, 2009

8 commits


29 Mar, 2009

6 commits

  • Move error reporting for RPC registration to rpcb_register's caller.

    This way the caller can choose to recover silently from certain
    errors, but report errors it does not recognize. Error reporting
    for kernel RPC service registration is now handled in one place.

    This patch is part of a series that addresses
    http://bugzilla.kernel.org/show_bug.cgi?id=12256

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • The user space TI-RPC library uses an empty string for the universal
    address when unregistering all target addresses for [program, version].
    The kernel's rpcb client should behave the same way.

    Here, we are switching between several registration methods based on
    the protocol family of the incoming address. Rename the other rpcbind
    v4 registration functions to make it clear that they, as well, are
    switched on protocol family. In /etc/netconfig, this is either "inet"
    or "inet6".

    NB: The loopback protocol families are not supported in the kernel.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • RFC 1833 has little to say about the contents of r_owner; it only
    specifies that it is a string, and states that it is used to control
    who can UNSET an entry.

    Our port of rpcbind (from Sun) assumes this string contains a numeric
    UID value, not alphabetical or symbolic characters, but checks this
    value only for AF_LOCAL RPCB_SET or RPCB_UNSET requests. In all other
    cases, rpcbind ignores the contents of the r_owner string.

    The reference user space implementation of rpcb_set(3) uses a numeric
    UID for all SET/UNSET requests (even via the network) and an empty
    string for all other requests. We emulate that behavior here to
    maintain bug-for-bug compatibility.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • Clean up: Simplify rpcb_v4_register() and its helpers by moving the
    details of sockaddr type casting to rpcb_v4_register()'s helper
    functions.

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • The kernel uses an IPv6 loopback address when registering its AF_INET6
    RPC services so that it can tell whether the local portmapper is
    actually IPv6-enabled.

    Since the legacy portmapper doesn't listen on IPv6, however, this
    causes a long timeout on older systems if the kernel happens to try
    creating and registering an AF_INET6 RPC service. Originally I wanted
    to use a connected transport (either TCP or connected UDP) so that the
    upcall would fail immediately if the portmapper wasn't listening on
    IPv6, but we never agreed on what transport to use.

    In the end, it's of little consequence to the kernel whether the local
    portmapper is listening on IPv6. It's only important whether the
    portmapper supports rpcbind v4. And the kernel can't tell that at all
    if it is sending requests via IPv6 -- the portmapper will just ignore
    them.

    So, send both rpcbind v2 and v4 SET/UNSET requests via IPv4 loopback
    to maintain better backwards compatibility between new kernels and
    legacy user space, and prevent multi-second hangs in some cases when
    the kernel attempts to register RPC services.

    This patch is part of a series that addresses

    http://bugzilla.kernel.org/show_bug.cgi?id=12256

    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     
  • In 2007, commit e65fe3976f594603ed7b1b4a99d3e9b867f573ea added
    additional sanity checking to rpcb_decode_getaddr() to make sure we
    were getting a reply that was long enough to be an actual universal
    address. If the uaddr string isn't long enough, the XDR decoder
    returns EIO.

    However, an empty string is a valid RPCB_GETADDR response if the
    requested service isn't registered. Moreover, "::.n.m" is also a
    valid RPCB_GETADDR response for IPv6 addresses that is shorter
    than rpcb_decode_getaddr()'s lower limit of 11. So this sanity
    check introduced a regression for rpcbind requests against IPv6
    remotes.

    So revert the lower bound check added by commit
    e65fe3976f594603ed7b1b4a99d3e9b867f573ea, and add an explicit check
    for an empty uaddr string, similar to libtirpc's rpcb_getaddr(3).

    Pointed-out-by: Jeff Layton
    Signed-off-by: Chuck Lever
    Signed-off-by: Trond Myklebust

    Chuck Lever
     

31 Oct, 2008

1 commit


30 Oct, 2008

1 commit


29 Oct, 2008

1 commit