1. 18 3月, 2017 1 次提交
  2. 02 12月, 2016 1 次提交
  3. 08 11月, 2016 1 次提交
  4. 05 10月, 2016 1 次提交
    • D
      fs: nfs: Make nfs boot time y2038 safe · 2f86e091
      Deepa Dinamani 提交于
      boot_time is represented as a struct timespec.
      struct timespec and CURRENT_TIME are not y2038 safe.
      Overall, the plan is to use timespec64 and ktime_t for
      all internal kernel representation of timestamps.
      CURRENT_TIME will also be removed.
      
      boot_time is used to construct the nfs client boot verifier.
      
      Use ktime_t to represent boot_time and ktime_get_real() for
      the boot_time value.
      
      Following Trond's request https://lkml.org/lkml/2016/6/9/22 ,
      use ktime_t instead of converting to struct timespec64.
      
      Use higher and lower 32 bit parts of ktime_t for the boot
      verifier.
      
      Use the lower 32 bit part of ktime_t for the authsys_parms
      stamp field.
      Signed-off-by: NDeepa Dinamani <deepa.kernel@gmail.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Anna Schumaker <anna.schumaker@netapp.com>
      Cc: linux-nfs@vger.kernel.org
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      2f86e091
  5. 20 9月, 2016 3 次提交
  6. 16 8月, 2016 1 次提交
  7. 01 7月, 2016 1 次提交
    • T
      NFS: Fix an Oops in the pNFS files and flexfiles connection setup to the DS · 5c6e5b60
      Trond Myklebust 提交于
      Chris Worley reports:
       RIP: 0010:[<ffffffffa0245f80>]  [<ffffffffa0245f80>] rpc_new_client+0x2a0/0x2e0 [sunrpc]
       RSP: 0018:ffff880158f6f548  EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff880234f8bc00 RCX: 000000000000ea60
       RDX: 0000000000074cc0 RSI: 000000000000ea60 RDI: ffff880234f8bcf0
       RBP: ffff880158f6f588 R08: 000000000001ac80 R09: ffff880237003300
       R10: ffff880201171000 R11: ffffea0000d75200 R12: ffffffffa03afc60
       R13: ffff880230c18800 R14: 0000000000000000 R15: ffff880158f6f680
       FS:  00007f0e32673740(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000008 CR3: 0000000234886000 CR4: 00000000001406e0
       Stack:
        ffffffffa047a680 0000000000000000 ffff880158f6f598 ffff880158f6f680
        ffff880158f6f680 ffff880234d11d00 ffff88023357f800 ffff880158f6f7d0
        ffff880158f6f5b8 ffffffffa024660a ffff880158f6f5b8 ffffffffa02492ec
       Call Trace:
        [<ffffffffa024660a>] rpc_create_xprt+0x1a/0xb0 [sunrpc]
        [<ffffffffa02492ec>] ? xprt_create_transport+0x13c/0x240 [sunrpc]
        [<ffffffffa0246766>] rpc_create+0xc6/0x1a0 [sunrpc]
        [<ffffffffa038e695>] nfs_create_rpc_client+0xf5/0x140 [nfs]
        [<ffffffffa038f31a>] nfs_init_client+0x3a/0xd0 [nfs]
        [<ffffffffa038f22f>] nfs_get_client+0x25f/0x310 [nfs]
        [<ffffffffa025cef8>] ? rpc_ntop+0xe8/0x100 [sunrpc]
        [<ffffffffa047512c>] nfs3_set_ds_client+0xcc/0x100 [nfsv3]
        [<ffffffffa041fa10>] nfs4_pnfs_ds_connect+0x120/0x400 [nfsv4]
        [<ffffffffa03d41c7>] nfs4_ff_layout_prepare_ds+0xe7/0x330 [nfs_layout_flexfiles]
        [<ffffffffa03d1b1b>] ff_layout_pg_init_write+0xcb/0x280 [nfs_layout_flexfiles]
        [<ffffffffa03a14dc>] __nfs_pageio_add_request+0x12c/0x490 [nfs]
        [<ffffffffa03a1fa2>] nfs_pageio_add_request+0xc2/0x2a0 [nfs]
        [<ffffffffa03a0365>] ? nfs_pageio_init+0x75/0x120 [nfs]
        [<ffffffffa03a5b50>] nfs_do_writepage+0x120/0x270 [nfs]
        [<ffffffffa03a5d31>] nfs_writepage_locked+0x61/0xc0 [nfs]
        [<ffffffff813d4115>] ? __percpu_counter_add+0x55/0x70
        [<ffffffffa03a6a9f>] nfs_wb_single_page+0xef/0x1c0 [nfs]
        [<ffffffff811ca4a3>] ? __dec_zone_page_state+0x33/0x40
        [<ffffffffa0395b21>] nfs_launder_page+0x41/0x90 [nfs]
        [<ffffffff811baba0>] invalidate_inode_pages2_range+0x340/0x3a0
        [<ffffffff811bac17>] invalidate_inode_pages2+0x17/0x20
        [<ffffffffa039960e>] nfs_release+0x9e/0xb0 [nfs]
        [<ffffffffa0399570>] ? nfs_open+0x60/0x60 [nfs]
        [<ffffffffa0394dad>] nfs_file_release+0x3d/0x60 [nfs]
        [<ffffffff81226e6c>] __fput+0xdc/0x1e0
        [<ffffffff81226fbe>] ____fput+0xe/0x10
        [<ffffffff810bf2e4>] task_work_run+0xc4/0xe0
        [<ffffffff810a4188>] do_exit+0x2e8/0xb30
        [<ffffffff8102471c>] ? do_audit_syscall_entry+0x6c/0x70
        [<ffffffff811464e6>] ? __audit_syscall_exit+0x1e6/0x280
        [<ffffffff810a4a5f>] do_group_exit+0x3f/0xa0
        [<ffffffff810a4ad4>] SyS_exit_group+0x14/0x20
        [<ffffffff8179b76e>] system_call_fastpath+0x12/0x71
      
      Which seems to be due to a call to utsname() when in a task exit context
      in order to determine the hostname to set in rpc_new_client().
      
      In reality, what we want here is not the hostname of the current task, but
      the hostname that was used to set up the metadata server.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      5c6e5b60
  8. 30 5月, 2016 1 次提交
  9. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov 提交于
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  10. 16 10月, 2015 1 次提交
  11. 18 8月, 2015 1 次提交
  12. 23 7月, 2015 1 次提交
  13. 01 7月, 2015 2 次提交
  14. 16 6月, 2015 1 次提交
    • K
      nfs: Fix showing truncated fsid/dev in, /proc/net/nfsfs/volumes · df05a49f
      Kinglong Mee 提交于
      A truncated fsid showing from /proc/fs/nfsfs/volumes as,
      NV SERVER   PORT DEV     FSID              FSC
      v4 c0a80881  801 0:43    34931f044c2a439b  no
      
      It should be as,
      NV SERVER   PORT DEV          FSID                              FSC
      v4 c0a80881  801 0:43         34931f044c2a439b:954c5d830fa4be8c no
      
      The max buffer length for storing "%llx:%llx" format should be
       16 + 1 + 16 + 1 = 34 (16 for %llx, 1 for ':', 1 for '\0').
      
      Also, for storing "%u:%u" of MAJOR() and MINOR() should be
       8 + 1 + 3 + 1 = 13 (8 for 2^24, 1 for ':', 3 for 2^8, 1 for '\0').
      
      v2, add comments for dev/fsid buffer and use sizeof in snprintf.
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      df05a49f
  15. 24 4月, 2015 1 次提交
  16. 04 3月, 2015 1 次提交
  17. 25 9月, 2014 1 次提交
  18. 11 9月, 2014 1 次提交
  19. 09 9月, 2014 1 次提交
    • C
      nfs: fix kernel warning when removing proc entry · 21e81002
      Cong Wang 提交于
      I saw the following kernel warning:
      
      [ 1852.321222] ------------[ cut here ]------------
      [ 1852.326527] WARNING: CPU: 0 PID: 118 at fs/proc/generic.c:521 remove_proc_entry+0x154/0x16b()
      [ 1852.335630] remove_proc_entry: removing non-empty directory 'fs/nfsfs', leaking at least 'volumes'
      [ 1852.344084] CPU: 0 PID: 118 Comm: kworker/u8:2 Not tainted 3.16.0+ #540
      [ 1852.350036] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [ 1852.354992] Workqueue: netns cleanup_net
      [ 1852.358701]  0000000000000000 ffff880116f2fbd0 ffffffff819c03e9 ffff880116f2fc18
      [ 1852.366474]  ffff880116f2fc08 ffffffff810744ee ffffffff811e0e6e ffff8800d4e96238
      [ 1852.373507]  ffffffff81dbe665 ffff8800d46a5948 0000000000000005 ffff880116f2fc68
      [ 1852.380224] Call Trace:
      [ 1852.381976]  [<ffffffff819c03e9>] dump_stack+0x4d/0x66
      [ 1852.385495]  [<ffffffff810744ee>] warn_slowpath_common+0x7a/0x93
      [ 1852.389869]  [<ffffffff811e0e6e>] ? remove_proc_entry+0x154/0x16b
      [ 1852.393987]  [<ffffffff8107457b>] warn_slowpath_fmt+0x4c/0x4e
      [ 1852.397999]  [<ffffffff811e0e6e>] remove_proc_entry+0x154/0x16b
      [ 1852.402034]  [<ffffffff8129c73d>] nfs_fs_proc_net_exit+0x53/0x56
      [ 1852.406136]  [<ffffffff812a103b>] nfs_net_exit+0x12/0x1d
      [ 1852.409774]  [<ffffffff81785bc9>] ops_exit_list+0x44/0x55
      [ 1852.413529]  [<ffffffff81786389>] cleanup_net+0xee/0x182
      [ 1852.417198]  [<ffffffff81088c9e>] process_one_work+0x209/0x40d
      [ 1852.502320]  [<ffffffff81088bf7>] ? process_one_work+0x162/0x40d
      [ 1852.587629]  [<ffffffff810890c1>] worker_thread+0x1f0/0x2c7
      [ 1852.673291]  [<ffffffff81088ed1>] ? process_scheduled_works+0x2f/0x2f
      [ 1852.759470]  [<ffffffff8108e079>] kthread+0xc9/0xd1
      [ 1852.843099]  [<ffffffff8109427f>] ? finish_task_switch+0x3a/0xce
      [ 1852.926518]  [<ffffffff8108dfb0>] ? __kthread_parkme+0x61/0x61
      [ 1853.008565]  [<ffffffff819cbeac>] ret_from_fork+0x7c/0xb0
      [ 1853.076477]  [<ffffffff8108dfb0>] ? __kthread_parkme+0x61/0x61
      [ 1853.140653] ---[ end trace 69c4c6617f78e32d ]---
      
      It looks wrong that we add "/proc/net/nfsfs" in nfs_fs_proc_net_init()
      while remove "/proc/fs/nfsfs" in nfs_fs_proc_net_exit().
      
      Fixes: commit 65b38851 (NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes)
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Dan Aloni <dan@kernelim.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      [Trond: replace uses of remove_proc_entry() with remove_proc_subtree()
      as suggested by Al Viro]
      Cc: stable@vger.kernel.org # 3.4.x : 65b38851: NFS: Fix /proc/fs/nfsfs/servers
      Cc: stable@vger.kernel.org # 3.4.x
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      21e81002
  20. 05 8月, 2014 1 次提交
    • E
      NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes · 65b38851
      Eric W. Biederman 提交于
      The usage of pid_ns->child_reaper->nsproxy->net_ns in
      nfs_server_list_open and nfs_client_list_open is not safe.
      
      /proc for a pid namespace can remain mounted after the all of the
      process in that pid namespace have exited.  There are also times
      before the initial process in a pid namespace has started or after the
      initial process in a pid namespace has exited where
      pid_ns->child_reaper can be NULL or stale.  Making the idiom
      pid_ns->child_reaper->nsproxy a double whammy of problems.
      
      Luckily all that needs to happen is to move /proc/fs/nfsfs/servers and
      /proc/fs/nfsfs/volumes under /proc/net to /proc/net/nfsfs/servers and
      /proc/net/nfsfs/volumes and add a symlink from the original location,
      and to use seq_open_net as it has been designed.
      
      Cc: stable@vger.kernel.org
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      65b38851
  21. 04 8月, 2014 1 次提交
  22. 13 7月, 2014 1 次提交
  23. 09 7月, 2014 1 次提交
  24. 29 10月, 2013 3 次提交
  25. 02 10月, 2013 1 次提交
  26. 08 8月, 2013 1 次提交
  27. 29 6月, 2013 1 次提交
  28. 09 6月, 2013 1 次提交
  29. 15 4月, 2013 1 次提交
  30. 28 2月, 2013 1 次提交
  31. 13 12月, 2012 1 次提交
    • N
      NFS: avoid NULL dereference in nfs_destroy_server · f259613a
      NeilBrown 提交于
      In rare circumstances, nfs_clone_server() of a v2 or v3 server can get
      an error between setting server->destory (to nfs_destroy_server), and
      calling nfs_start_lockd (which will set server->nlm_host).
      
      If this happens, nfs_clone_server will call nfs_free_server which
      will call nfs_destroy_server and thence nlmclnt_done(NULL).  This
      causes the NULL to be dereferenced.
      
      So add a guard to only call nlmclnt_done() if ->nlm_host is not NULL.
      
      The other guards there are irrelevant as nlm_host can only be non-NULL
      if one of these flags are set - so remove those tests.  (Thanks to Trond
      for this suggestion).
      
      This is suitable for any stable kernel since 2.6.25.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f259613a
  32. 05 11月, 2012 1 次提交
  33. 02 10月, 2012 3 次提交
    • Y
      NFS: Remove unnecessary semicolons (fs/nfs/client.c) · ee34e136
      Yanchuan Nian 提交于
      There are some unnecessary semicolons in function find_nfs_version. Just remove them.
      Signed-off-by: NYanchuan Nian <ycnian@gmail.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ee34e136
    • P
      NFS41: fix error of setting blocklayoutdriver · dc182549
      Peng Tao 提交于
      After commit e38eb650 (NFS: set_pnfs_layoutdriver() from
      nfs4_proc_fsinfo()), set_pnfs_layoutdriver() is called inside
      nfs4_proc_fsinfo(), but pnfs_blksize is not set. It causes setting
      blocklayoutdriver failure and pnfsblock mount failure.
      
      Cc: stable <stable@vger.kernel.org> [since v3.5]
      Signed-off-by: NPeng Tao <tao.peng@emc.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      dc182549
    • C
      NFS: Discover NFSv4 server trunking when mounting · 05f4c350
      Chuck Lever 提交于
      "Server trunking" is a fancy named for a multi-homed NFS server.
      Trunking might occur if a client sends NFS requests for a single
      workload to multiple network interfaces on the same server.  There
      are some implications for NFSv4 state management that make it useful
      for a client to know if a single NFSv4 server instance is
      multi-homed.  (Note this is only a consideration for NFSv4, not for
      legacy versions of NFS, which are stateless).
      
      If a client cares about server trunking, no NFSv4 operations can
      proceed until that client determines who it is talking to.  Thus
      server IP trunking discovery must be done when the client first
      encounters an unfamiliar server IP address.
      
      The nfs_get_client() function walks the nfs_client_list and matches
      on server IP address.  The outcome of that walk tells us immediately
      if we have an unfamiliar server IP address.  It invokes
      nfs_init_client() in this case.  Thus, nfs4_init_client() is a good
      spot to perform trunking discovery.
      
      Discovery requires a client to establish a fresh client ID, so our
      client will now send SETCLIENTID or EXCHANGE_ID as the first NFS
      operation after a successful ping, rather than waiting for an
      application to perform an operation that requires NFSv4 state.
      
      The exact process for detecting trunking is different for NFSv4.0 and
      NFSv4.1, so a minorversion-specific init_client callout method is
      introduced.
      
      CLID_INUSE recovery is important for the trunking discovery process.
      CLID_INUSE is a sign the server recognizes the client's nfs_client_id4
      id string, but the client is using the wrong principal this time for
      the SETCLIENTID operation.  The SETCLIENTID must be retried with a
      series of different principals until one works, and then the rest of
      trunking discovery can proceed.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      05f4c350