1. 24 Jan, 2017 1 commit
    • Kinglong Mee's avatar
      SUNRPC: cleanup ida information when removing sunrpc module · c929ea0b
      Kinglong Mee authored
      After removing sunrpc module, I get many kmemleak information as,
      unreferenced object 0xffff88003316b1e0 (size 544):
        comm "gssproxy", pid 2148, jiffies 4294794465 (age 4200.081s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffffb0cfb58a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffffb03507fe>] kmem_cache_alloc+0x15e/0x1f0
          [<ffffffffb0639baa>] ida_pre_get+0xaa/0x150
          [<ffffffffb0639cfd>] ida_simple_get+0xad/0x180
          [<ffffffffc06054fb>] nlmsvc_lookup_host+0x4ab/0x7f0 [lockd]
          [<ffffffffc0605e1d>] lockd+0x4d/0x270 [lockd]
          [<ffffffffc06061e5>] param_set_timeout+0x55/0x100 [lockd]
          [<ffffffffc06cba24>] svc_defer+0x114/0x3f0 [sunrpc]
          [<ffffffffc06cbbe7>] svc_defer+0x2d7/0x3f0 [sunrpc]
          [<ffffffffc06c71da>] rpc_show_info+0x8a/0x110 [sunrpc]
          [<ffffffffb044a33f>] proc_reg_write+0x7f/0xc0
          [<ffffffffb038e41f>] __vfs_write+0xdf/0x3c0
          [<ffffffffb0390f1f>] vfs_write+0xef/0x240
          [<ffffffffb0392fbd>] SyS_write+0xad/0x130
          [<ffffffffb0d06c37>] entry_SYSCALL_64_fastpath+0x1a/0xa9
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      I found, the ida information (dynamic memory) isn't cleanup.
      Signed-off-by: default avatarKinglong Mee <kinglongmee@gmail.com>
      Fixes: 2f048db4 ("SUNRPC: Add an identifier for struct rpc_clnt")
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      c929ea0b
  2. 18 Nov, 2016 1 commit
    • Alexey Dobriyan's avatar
      netns: make struct pernet_operations::id unsigned int · c7d03a00
      Alexey Dobriyan authored
      Make struct pernet_operations::id unsigned.
      
      There are 2 reasons to do so:
      
      1)
      This field is really an index into an zero based array and
      thus is unsigned entity. Using negative value is out-of-bound
      access by definition.
      
      2)
      On x86_64 unsigned 32-bit data which are mixed with pointers
      via array indexing or offsets added or subtracted to pointers
      are preffered to signed 32-bit data.
      
      "int" being used as an array index needs to be sign-extended
      to 64-bit before being used.
      
      	void f(long *p, int i)
      	{
      		g(p[i]);
      	}
      
        roughly translates to
      
      	movsx	rsi, esi
      	mov	rdi, [rsi+...]
      	call 	g
      
      MOVSX is 3 byte instruction which isn't necessary if the variable is
      unsigned because x86_64 is zero extending by default.
      
      Now, there is net_generic() function which, you guessed it right, uses
      "int" as an array index:
      
      	static inline void *net_generic(const struct net *net, int id)
      	{
      		...
      		ptr = ng->ptr[id - 1];
      		...
      	}
      
      And this function is used a lot, so those sign extensions add up.
      
      Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
      messing with code generation):
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      
      Unfortunately some functions actually grow bigger.
      This is a semmingly random artefact of code generation with register
      allocator being used differently. gcc decides that some variable
      needs to live in new r8+ registers and every access now requires REX
      prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
      used which is longer than [r8]
      
      However, overall balance is in negative direction:
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      	function                                     old     new   delta
      	nfsd4_lock                                  3886    3959     +73
      	tipc_link_build_proto_msg                   1096    1140     +44
      	mac80211_hwsim_new_radio                    2776    2808     +32
      	tipc_mon_rcv                                1032    1058     +26
      	svcauth_gss_legacy_init                     1413    1429     +16
      	tipc_bcbase_select_primary                   379     392     +13
      	nfsd4_exchange_id                           1247    1260     +13
      	nfsd4_setclientid_confirm                    782     793     +11
      		...
      	put_client_renew_locked                      494     480     -14
      	ip_set_sockfn_get                            730     716     -14
      	geneve_sock_add                              829     813     -16
      	nfsd4_sequence_done                          721     703     -18
      	nlmclnt_lookup_host                          708     686     -22
      	nfsd4_lockt                                 1085    1063     -22
      	nfs_get_client                              1077    1050     -27
      	tcf_bpf_init                                1106    1076     -30
      	nfsd4_encode_fattr                          5997    5930     -67
      	Total: Before=154856051, After=154854321, chg -0.00%
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7d03a00
  3. 23 Apr, 2015 1 commit
    • Jeff Layton's avatar
      sunrpc: make debugfs file creation failure non-fatal · 3f940098
      Jeff Layton authored
      v2: gracefully handle the case where some dentry pointers end up NULL
          and be more dilligent about zeroing out dentry pointers
      
      We currently have a problem that SELinux policy is being enforced when
      creating debugfs files. If a debugfs file is created as a side effect of
      doing some syscall, then that creation can fail if the SELinux policy
      for that process prevents it.
      
      This seems wrong. We don't do that for files under /proc, for instance,
      so Bruce has proposed a patch to fix that.
      
      While discussing that patch however, Greg K.H. stated:
      
          "No kernel code should care / fail if a debugfs function fails, so
           please fix up the sunrpc code first."
      
      This patch converts all of the sunrpc debugfs setup code to be void
      return functins, and the callers to not look for errors from those
      functions.
      
      This should allow rpc_clnt and rpc_xprt creation to work, even if the
      kernel fails to create debugfs files for some reason.
      
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      3f940098
  4. 31 Mar, 2015 1 commit
    • Jeff Layton's avatar
      sunrpc: make debugfs file creation failure non-fatal · f9c72d10
      Jeff Layton authored
      We currently have a problem that SELinux policy is being enforced when
      creating debugfs files. If a debugfs file is created as a side effect of
      doing some syscall, then that creation can fail if the SELinux policy
      for that process prevents it.
      
      This seems wrong. We don't do that for files under /proc, for instance,
      so Bruce has proposed a patch to fix that.
      
      While discussing that patch however, Greg K.H. stated:
      
          "No kernel code should care / fail if a debugfs function fails, so
           please fix up the sunrpc code first."
      
      This patch converts all of the sunrpc debugfs setup code to be void
      return functins, and the callers to not look for errors from those
      functions.
      
      This should allow rpc_clnt and rpc_xprt creation to work, even if the
      kernel fails to create debugfs files for some reason.
      
      Symptoms were failing krb5 mounts on systems using gss-proxy and
      selinux.
      
      Fixes: 388f0c77 "sunrpc: add a debugfs rpc_xprt directory..."
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      f9c72d10
  5. 27 Nov, 2014 1 commit
    • Jeff Layton's avatar
      sunrpc: add debugfs file for displaying client rpc_task queue · b4b9d2cc
      Jeff Layton authored
      It's possible to get a dump of the RPC task queue by writing a value to
      /proc/sys/sunrpc/rpc_debug. If you write any value to that file, you get
      a dump of the RPC client task list into the log buffer. This is a rather
      inconvenient interface however, and makes it hard to get immediate info
      about the task queue.
      
      Add a new directory hierarchy under debugfs:
      
          sunrpc/
              rpc_clnt/
                  <clientid>/
      
      Within each clientid directory we create a new "tasks" file that will
      dump info similar to what shows up in the log buffer, but with a few
      small differences -- we avoid printing raw kernel addresses in favor of
      symbolic names and the XID is also displayed.
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      b4b9d2cc
  6. 24 Nov, 2014 1 commit
  7. 06 Dec, 2013 1 commit
    • Jeff Layton's avatar
      sunrpc: create a new dummy pipe for gssd to hold open · 4b9a445e
      Jeff Layton authored
      rpc.gssd will naturally hold open any pipe named */clnt*/gssd that shows
      up under rpc_pipefs. That behavior gives us a reliable mechanism to tell
      whether it's actually running or not.
      
      Create a new toplevel "gssd" directory in rpc_pipefs when it's mounted.
      Under that directory create another directory called "clntXX", and then
      within that a pipe called "gssd".
      
      We'll never send an upcall along that pipe, and any downcall written to
      it will just return -EINVAL.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4b9a445e
  8. 18 Apr, 2012 1 commit
  9. 11 Mar, 2012 1 commit
    • Trond Myklebust's avatar
      SUNRPC: Fix a few sparse warnings · 09acfea5
      Trond Myklebust authored
      net/sunrpc/svcsock.c:412:22: warning: incorrect type in assignment
      (different address spaces)
       - svc_partial_recvfrom now takes a struct kvec, so the variable
         save_iovbase needs to be an ordinary (void *)
      
      Make a bunch of variables in net/sunrpc/xprtsock.c static
      
      Fix a couple of "warning: symbol 'foo' was not declared. Should it be
      static?" reports.
      
      Fix a couple of conflicting function declarations.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      09acfea5
  10. 16 Feb, 2012 1 commit
  11. 01 Feb, 2012 2 commits
  12. 31 Jan, 2012 2 commits
  13. 25 Oct, 2011 1 commit
  14. 27 Sep, 2010 3 commits
  15. 04 Aug, 2010 1 commit
  16. 06 Jul, 2010 1 commit
    • Artem Bityutskiy's avatar
      sunrpc: make the cache cleaner workqueue deferrable · 8eab945c
      Artem Bityutskiy authored
      This patch makes the cache_cleaner workqueue deferrable, to prevent
      unnecessary system wake-ups, which is very important for embedded
      battery-powered devices.
      
      do_cache_clean() is called every 30 seconds at the moment, and often
      makes the system wake up from its power-save sleep state. With this
      change, when the workqueue uses a deferrable timer, the
      do_cache_clean() invocation will be delayed and combined with the
      closest "real" wake-up. This improves the power consumption situation.
      
      Note, I tried to create a DECLARE_DELAYED_WORK_DEFERRABLE() helper
      macro, similar to DECLARE_DELAYED_WORK(), but failed because of the
      way the timer wheel core stores the deferrable flag (it is the
      LSBit in the time->base pointer). My attempt to define a static
      variable with this bit set ended up with the "initializer element is
      not constant" error.
      
      Thus, I have to use run-time initialization, so I created a new
      cache_initialize() function which is called once when sunrpc is
      being initialized.
      Signed-off-by: default avatarArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      8eab945c
  17. 03 Dec, 2009 1 commit
    • Chuck Lever's avatar
      SUNRPC: Use a cached RPC client and transport for rpcbind upcalls · c526611d
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      c526611d
  18. 21 Aug, 2009 1 commit
  19. 26 Jun, 2009 1 commit
  20. 01 Feb, 2008 4 commits
  21. 30 Jan, 2008 1 commit
  22. 06 Dec, 2007 1 commit
  23. 09 Oct, 2007 1 commit
  24. 11 Jul, 2007 6 commits
  25. 14 May, 2007 1 commit
  26. 09 May, 2007 1 commit
  27. 14 Feb, 2007 2 commits