1. 09 7月, 2014 7 次提交
    • J
      nfsd4: remove nfs4_acl_new · bcaab953
      J. Bruce Fields 提交于
      This is a not-that-useful kmalloc wrapper.  And I'd like one of the
      callers to actually use something other than kmalloc.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      bcaab953
    • J
      29c353b3
    • J
      nfsd4: remove unused defer_free argument · ce043ac8
      J. Bruce Fields 提交于
      28e05dd8 "knfsd: nfsd4: represent nfsv4 acl with array instead of
      linked list" removed the last user that wanted a custom free function.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ce043ac8
    • J
      nfsd4: rename cr_linkname->cr_data · 7fb84306
      J. Bruce Fields 提交于
      The name of a link is currently stored in cr_name and cr_namelen, and
      the content in cr_linkname and cr_linklen.  That's confusing.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7fb84306
    • J
      nfsd: let nfsd_symlink assume null-terminated data · 52ee0433
      J. Bruce Fields 提交于
      Currently nfsd_symlink has a weird hack to serve callers who don't
      null-terminate symlink data: it looks ahead at the next byte to see if
      it's zero, and copies it to a new buffer to null-terminate if not.
      
      That means callers don't have to null-terminate, but they *do* have to
      ensure that the byte following the end of the data is theirs to read.
      
      That's a bit subtle, and the NFSv4 code actually got this wrong.
      
      So let's just throw out that code and let callers pass null-terminated
      strings; we've already fixed them to do that.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      52ee0433
    • J
      nfsd: make NFSv2 null terminate symlink data · 0aeae33f
      J. Bruce Fields 提交于
      It's simple enough for NFSv2 to null-terminate the symlink data.
      
      A bit weird (it depends on knowing that we've already read the following
      byte, which is either padding or part of the mode), but no worse than
      the conditional kstrdup it otherwise relies on in nfsd_symlink().
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      0aeae33f
    • J
      nfsd: fix rare symlink decoding bug · b829e919
      J. Bruce Fields 提交于
      An NFS operation that creates a new symlink includes the symlink data,
      which is xdr-encoded as a length followed by the data plus 0 to 3 bytes
      of zero-padding as required to reach a 4-byte boundary.
      
      The vfs, on the other hand, wants null-terminated data.
      
      The simple way to handle this would be by copying the data into a newly
      allocated buffer with space for the final null.
      
      The current nfsd_symlink code tries to be more clever by skipping that
      step in the (likely) case where the byte following the string is already
      0.
      
      But that assumes that the byte following the string is ours to look at.
      In fact, it might be the first byte of a page that we can't read, or of
      some object that another task might modify.
      
      Worse, the NFSv4 code tries to fix the problem by actually writing to
      that byte.
      
      In the NFSv2/v3 cases this actually appears to be safe:
      
      	- nfs3svc_decode_symlinkargs explicitly null-terminates the data
      	  (after first checking its length and copying it to a new
      	  page).
      	- NFSv2 limits symlinks to 1k.  The buffer holding the rpc
      	  request is always at least a page, and the link data (and
      	  previous fields) have maximum lengths that prevent the request
      	  from reaching the end of a page.
      
      In the NFSv4 case the CREATE op is potentially just one part of a long
      compound so can end up on the end of a page if you're unlucky.
      
      The minimal fix here is to copy and null-terminate in the NFSv4 case.
      The nfsd_symlink() interface here seems too fragile, though.  It should
      really either do the copy itself every time or just require a
      null-terminated string.
      Reported-by: NJeff Layton <jlayton@primarydata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b829e919
  2. 23 6月, 2014 10 次提交
  3. 18 6月, 2014 2 次提交
    • K
      NFSD: fix bug for readdir of pseudofs · f41c5ad2
      Kinglong Mee 提交于
      Commit 561f0ed4 (nfsd4: allow large readdirs) introduces a bug
      about readdir the root of pseudofs.
      
      Call xdr_truncate_encode() revert encoded name when skipping.
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f41c5ad2
    • N
      NFSD: Don't hand out delegations for 30 seconds after recalling them. · 6282cd56
      NeilBrown 提交于
      If nfsd needs to recall a delegation for some reason it implies that there is
      contention on the file, so further delegations should not be handed out.
      
      The current code fails to do so, and the result is effectively a
      live-lock under some workloads: a client attempting a conflicting
      operation on a read-delegated file receives NFS4ERR_DELAY and retries
      the operation, but by the time it retries the server may already have
      given out another delegation.
      
      We could simply avoid delegations for (say) 30 seconds after any recall, but
      this is probably too heavy handed.
      
      We could keep a list of inodes (or inode numbers or filehandles) for recalled
      delegations, but that requires memory allocation and searching.
      
      The approach taken here is to use a bloom filter to record the filehandles
      which are currently blocked from delegation, and to accept the cost of a few
      false positives.
      
      We have 2 bloom filters, each of which is valid for 30 seconds.   When a
      delegation is recalled the filehandle is added to one filter and will remain
      disabled for between 30 and 60 seconds.
      
      We keep a count of the number of filehandles that have been added, so when
      that count is zero we can bypass all other tests.
      
      The bloom filters have 256 bits and 3 hash functions.  This should allow a
      couple of dozen blocked  filehandles with minimal false positives.  If many
      more filehandles are all blocked at once, behaviour will degrade towards
      rejecting all delegations for between 30 and 60 seconds, then resetting and
      allowing new delegations.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      6282cd56
  4. 10 6月, 2014 1 次提交
  5. 07 6月, 2014 4 次提交
    • J
      nfsd: don't halt scanning the DRC LRU list when there's an RC_INPROG entry · 1b19453d
      Jeff Layton 提交于
      Currently, the DRC cache pruner will stop scanning the list when it
      hits an entry that is RC_INPROG. It's possible however for a call to
      take a *very* long time. In that case, we don't want it to block other
      entries from being pruned if they are expired or we need to trim the
      cache to get back under the limit.
      
      Fix the DRC cache pruner to just ignore RC_INPROG entries.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      1b19453d
    • J
      nfsd4: kill READ64 · 542d1ab3
      J. Bruce Fields 提交于
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      542d1ab3
    • J
      nfsd4: kill READ32 · 06553991
      J. Bruce Fields 提交于
      While we're here, let's kill off a couple of the read-side macros.
      
      Leaving the more complicated ones alone for now.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      06553991
    • J
      nfsd4: simplify server xdr->next_page use · 05638dc7
      J. Bruce Fields 提交于
      The rpc code makes available to the NFS server an array of pages to
      encod into.  The server represents its reply as an xdr buf, with the
      head pointing into the first page in that array, the pages ** array
      starting just after that, and the tail (if any) sharing any leftover
      space in the page used by the head.
      
      While encoding, we use xdr_stream->page_ptr to keep track of which page
      we're currently using.
      
      Currently we set xdr_stream->page_ptr to buf->pages, which makes the
      head a weird exception to the rule that page_ptr always points to the
      page we're currently encoding into.  So, instead set it to buf->pages -
      1 (the page actually containing the head), and remove the need for a
      little unintuitive logic in xdr_get_next_encode_buffer() and
      xdr_truncate_encode.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      05638dc7
  6. 05 6月, 2014 5 次提交
  7. 31 5月, 2014 11 次提交