1. 25 Sep, 2019 1 commit
  2. 23 Sep, 2019 2 commits
  3. 20 Sep, 2019 2 commits
    • NeilBrown's avatar
      nfsd: degraded slot-count more gracefully as allocation nears exhaustion. · 2030ca56
      NeilBrown authored
      This original code in nfsd4_get_drc_mem() would hand out 30
      slots (approximately NFSD_MAX_MEM_PER_SESSION bytes at slightly
      over 2K per slot) to each requesting client until it ran out
      of space, then it would possibly give one last client a reduced
      allocation, then fail the allocation.
      
      Since commit de766e57 ("nfsd: give out fewer session slots as
      limit approaches") the last 90 slots to be given to about 12
      clients with quickly reducing slot counts (better than just 3
      clients).  This still seems unnecessarily hasty.
      A subsequent patch allows over-allocation so every client gets
      at least one slot, but that might be a bit restrictive.
      
      The requested number of nfsd threads is the best guide we have to the
      expected number of clients, so use that - if it is at least 8.
      
      256 threads on a 256Meg machine - which is a lot for a tiny machine -
      would result in nfsd_drc_max_mem being 2Meg, so 8K (3 slots) would be
      available for the first client, and over 200 clients would get more
      than 1 slot.  So I don't think this change will be too debilitating on
      poorly configured machines, though it does mean that a sensible
      configuration is a little more important.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2030ca56
    • NeilBrown's avatar
      nfsd: handle drc over-allocation gracefully. · 7f49fd5d
      NeilBrown authored
      Currently, if there are more clients than allowed for by the
      space allocation in set_max_drc(), we fail a SESSION_CREATE
      request with NFS4ERR_DELAY.
      This means that the client retries indefinitely, which isn't
      a user-friendly response.
      
      The RFC requires NFS4ERR_NOSPC, but that would at best result in a
      clean failure on the client, which is not much more friendly.
      
      The current space allocation is a best-guess and doesn't provide any
      guarantees, we could still run out of space when trying to allocate
      drc space.
      
      So fail more gracefully - always give out at least one slot.
      If all clients used all the space in all slots, we might start getting
      memory pressure, but that is possible anyway.
      
      So ensure 'num' is always at least 1, and remove the test for it
      being zero.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      7f49fd5d
  4. 10 Sep, 2019 6 commits
  5. 29 Aug, 2019 1 commit
    • J. Bruce Fields's avatar
      nfsd: eliminate an unnecessary acl size limit · 2b86e3aa
      J. Bruce Fields authored
      We're unnecessarily limiting the size of an ACL to less than what most
      filesystems will support.  Some users do hit the limit and it's
      confusing and unnecessary.
      
      It still seems prudent to impose some limit on the number of ACEs the
      client gives us before passing it straight to kmalloc().  So, let's just
      limit it to the maximum number that would be possible given the amount
      of data left in the argument buffer.
      
      That will still leave one limit beyond whatever the filesystem imposes:
      the client and server negotiate a limit on the size of a request, which
      we have to respect.
      
      But we're no longer imposing any additional arbitrary limit.
      
      struct nfs4_ace is 20 bytes on my system and the maximum call size we'll
      negotiate is about a megabyte, so in practice this is limiting the
      allocation here to about a megabyte.
      Reported-by: default avatar"de Vandiere, Louis" <louis.devandiere@atos.net>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      2b86e3aa
  6. 26 Aug, 2019 1 commit
    • J. Bruce Fields's avatar
      Deprecate nfsd fault injection · 9d60d931
      J. Bruce Fields authored
      This is only useful for client testing.  I haven't really maintained it,
      and reference counting and locking are wrong at this point.  You can get
      some of the same functionality now from nfsd/clients/.
      
      It was a good idea but I think its time has passed.
      
      In the unlikely event of users, hopefully the BROKEN dependency will
      prompt them to speak up.  Otherwise I expect to remove it soon.
      Reported-by: default avatarAlex Lyakas <alex@zadara.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9d60d931
  7. 20 Aug, 2019 1 commit
  8. 19 Aug, 2019 18 commits
  9. 16 Aug, 2019 3 commits
    • J. Bruce Fields's avatar
      nfsd: Remove unnecessary NULL checks · 10fa8acf
      J. Bruce Fields authored
      "cb" is never actually NULL in these functions.
      
      On a quick skim of the history, they seem to have been there from the
      beginning.  I'm not sure if they originally served a purpose.
      Reported-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      10fa8acf
    • J. Bruce Fields's avatar
      Merge nfsd bugfixes · 4f375483
      J. Bruce Fields authored
      These are some nfsd bugfixes that I also want in the main branch that
      will be submitted for the 5.4 merge window.
      4f375483
    • He Zhe's avatar
      nfsd4: Fix kernel crash when reading proc file reply_cache_stats · 78e70e78
      He Zhe authored
      reply_cache_stats uses wrong parameter as seq file private structure and
      thus causes the following kernel crash when users read
      /proc/fs/nfsd/reply_cache_stats
      
      BUG: kernel NULL pointer dereference, address: 00000000000001f9
      PGD 0 P4D 0
      Oops: 0000 [#3] SMP PTI
      CPU: 6 PID: 1502 Comm: cat Tainted: G      D           5.3.0-rc3+ #1
      Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge, BIOS BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
      RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
      Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
      RSP: 0018:ffffaa520106fe08 EFLAGS: 00010246
      RAX: 000000cfe1a77123 RBX: 0000000000000000 RCX: 0000000000291b46
      RDX: 000000cf00000000 RSI: 0000000000000006 RDI: 0000000000291b28
      RBP: ffffaa520106fe20 R08: 0000000000000006 R09: 000000cfe17e55dd
      R10: ffffa424e47c0000 R11: 000000000000030b R12: 0000000000000001
      R13: ffffa424e5697000 R14: 0000000000000001 R15: ffffa424e5697000
      FS:  00007f805735f580(0000) GS:ffffa424f8f80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000001f9 CR3: 00000000655ce005 CR4: 00000000003606e0
      Call Trace:
       seq_read+0x194/0x3e0
       __vfs_read+0x1b/0x40
       vfs_read+0x95/0x140
       ksys_read+0x61/0xe0
       __x64_sys_read+0x1a/0x20
       do_syscall_64+0x4d/0x120
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f805728b861
      Code: fe ff ff 50 48 8d 3d 86 b4 09 00 e8 79 e0 01 00 66 0f 1f 84 00 00 00 00 00 48 8d 05 d9 19 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
      RSP: 002b:00007ffea1ce3c38 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f805728b861
      RDX: 0000000000020000 RSI: 00007f8057183000 RDI: 0000000000000003
      RBP: 00007f8057183000 R08: 00007f8057182010 R09: 0000000000000000
      R10: 0000000000000022 R11: 0000000000000246 R12: 0000559a60e8ff10
      R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
      Modules linked in:
      CR2: 00000000000001f9
      ---[ end trace 01613595153f0cba ]---
      RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
      Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
      RSP: 0018:ffffaa52004b3e08 EFLAGS: 00010246
      RAX: 0000002bab45a7c6 RBX: 0000000000000000 RCX: 0000000000291b4c
      RDX: 0000002b00000000 RSI: 0000000000000004 RDI: 0000000000291b28
      RBP: ffffaa52004b3e20 R08: 0000000000000004 R09: 0000002bab1c8c7a
      R10: ffffa424e5500000 R11: 00000000000002a9 R12: 0000000000000001
      R13: ffffa424e4475000 R14: 0000000000000001 R15: ffffa424e4475000
      FS:  00007f805735f580(0000) GS:ffffa424f8f80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000001f9 CR3: 00000000655ce005 CR4: 00000000003606e0
      Killed
      
      Fixes: 3ba75830 ("nfsd4: drc containerization")
      Signed-off-by: default avatarHe Zhe <zhe.he@windriver.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      78e70e78
  10. 15 Aug, 2019 3 commits
  11. 30 Jul, 2019 1 commit
    • Dave Wysochanski's avatar
      SUNRPC: Track writers of the 'channel' file to improve cache_listeners_exist · 64a38e84
      Dave Wysochanski authored
      The sunrpc cache interface is susceptible to being fooled by a rogue
      process just reading a 'channel' file.  If this happens the kernel
      may think a valid daemon exists to service the cache when it does not.
      For example, the following may fool the kernel:
      cat /proc/net/rpc/auth.unix.gid/channel
      
      Change the tracking of readers to writers when considering whether a
      listener exists as all valid daemon processes either open a channel
      file O_RDWR or O_WRONLY.  While this does not prevent a rogue process
      from "stealing" a message from the kernel, it does at least improve
      the kernels perception of whether a valid process servicing the cache
      exists.
      Signed-off-by: default avatarDave Wysochanski <dwysocha@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      64a38e84
  12. 28 Jul, 2019 1 commit