Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 4月, 2015 2 次提交
  3. 26 3月, 2015 1 次提交
  5. 21 3月, 2015 1 次提交
  7. 03 2月, 2015 1 次提交
    • C
      nfsd: implement pNFS operations · 9cf514cc
      由 Christoph Hellwig 提交于 
      Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
outstanding layouts and devices.

Layout management is very straight forward, with a nfs4_layout_stateid
structure that extends nfs4_stid to manage layout stateids as the
top-level structure.  It is linked into the nfs4_file and nfs4_client
structures like the other stateids, and contains a linked list of
layouts that hang of the stateid.  The actual layout operations are
implemented in layout drivers that are not part of this commit, but
will be added later.

The worst part of this commit is the management of the pNFS device IDs,
which suffers from a specification that is not sanely implementable due
to the fact that the device-IDs are global and not bound to an export,
and have a small enough size so that we can't store the fsid portion of
a file handle, and must never be reused.  As we still do need perform all
export authentication and validation checks on a device ID passed to
GETDEVICEINFO we are caught between a rock and a hard place.  To work
around this issue we add a new hash that maps from a 64-bit integer to a
fsid so that we can look up the export to authenticate against it,
a 32-bit integer as a generation that we can bump when changing the device,
and a currently unused 32-bit integer that could be used in the future
to handle more than a single device per export.  Entries in this hash
table are never deleted as we can't reuse the ids anyway, and would have
a severe lifetime problem anyway as Linux export structures are temporary
structures that can go away under load.

Parts of the XDR data, structures and marshaling/unmarshaling code, as
well as many concepts are derived from the old pNFS server implementation
from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
Mike Sager, Ricardo Labiaga and many others.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      9cf514cc
  9. 23 1月, 2015 1 次提交
  11. 08 1月, 2015 1 次提交
    • J
      nfsd4: tweak rd_dircount accounting · 0ec016e3
      由 J. Bruce Fields 提交于 
      RFC 3530 14.2.24 says

	This value represents the length of the names of the directory
	entries and the cookie value for these entries.  This length
	represents the XDR encoding of the data (names and cookies)...

The "xdr encoding" of the name should probably include the 4 bytes for
the length.

But this is all just a hint so not worth e.g. backporting to stable.

Also reshuffle some lines to more clearly group together the
dircount-related code.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      0ec016e3
  13. 10 12月, 2014 3 次提交
  15. 20 11月, 2014 1 次提交
  17. 08 11月, 2014 2 次提交
  19. 01 10月, 2014 1 次提交
    • J
      nfsd4: fix corruption of NFSv4 read data · 15b23ef5
      由 J. Bruce Fields 提交于 
      The calculation of page_ptr here is wrong in the case the read doesn't
start at an offset that is a multiple of a page.

The result is that nfs4svc_encode_compoundres sets rq_next_page to a
value one too small, and then the loop in svc_free_res_pages may
incorrectly fail to clear a page pointer in rq_respages[].

Pages left in rq_respages[] are available for the next rpc request to
use, so xdr data may be written to that page, which may hold data still
waiting to be transmitted to the client or data in the page cache.

The observed result was silent data corruption seen on an NFSv4 client.

We tag this as "fixing" 05638dc7 because that commit exposed this
bug, though the incorrect calculation predates it.

Particular thanks to Andrea Arcangeli and David Gilbert for analysis and
testing.

Fixes: 05638dc7 "nfsd4: simplify server xdr->next_page use"
Cc: stable@vger.kernel.org
Reported-by: NAndrea Arcangeli <aarcange@redhat.com>
Tested-by: N"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      15b23ef5
  21. 30 9月, 2014 2 次提交
  23. 09 9月, 2014 1 次提交
  25. 18 8月, 2014 2 次提交
  27. 01 8月, 2014 1 次提交
  29. 23 7月, 2014 1 次提交
    • K
      NFSD: Fix crash encoding lock reply on 32-bit · f98bac5a
      由 Kinglong Mee 提交于 
      Commit 8c7424cf "nfsd4: don't try to encode conflicting owner if low
on space" forgot to free conf->data in nfsd4_encode_lockt and before
sign conf->data to NULL in nfsd4_encode_lock_denied, causing a leak.

Worse, kfree() can be called on an uninitialized pointer in the case of
a succesful lock (or one that fails for a reason other than a conflict).

(Note that lock->lk_denied.ld_owner.data appears it should be zero here,
until you notice that it's one arm of a union the other arm of which is
written to in the succesful case by the

	memcpy(&lock->lk_resp_stateid, &lock_stp->st_stid.sc_stateid,
	                                sizeof(stateid_t));

in nfsd4_lock().  In the 32-bit case this overwrites ld_owner.data.)
Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
Fixes: 8c7424cf ""nfsd4: don't try to encode conflicting owner if low on space"
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f98bac5a
  31. 18 7月, 2014 1 次提交
    • J
      nfsd4: zero op arguments beyond the 8th compound op · 5d6031ca
      由 J. Bruce Fields 提交于 
      The first 8 ops of the compound are zeroed since they're a part of the
argument that's zeroed by the

	memset(rqstp->rq_argp, 0, procp->pc_argsize);

in svc_process_common().  But we handle larger compounds by allocating
the memory on the fly in nfsd4_decode_compound().  Other than code
recently fixed by 01529e3f "NFSD: Fix memory leak in encoding denied
lock", I don't know of any examples of code depending on this
initialization. But it definitely seems possible, and I'd rather be
safe.

Compounds this long are unusual so I'm much more worried about failure
in this poorly tested cases than about an insignificant performance hit.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      5d6031ca
  33. 12 7月, 2014 1 次提交
  35. 10 7月, 2014 1 次提交
  37. 09 7月, 2014 8 次提交
  39. 08 7月, 2014 1 次提交
  41. 03 7月, 2014 1 次提交
  43. 28 6月, 2014 1 次提交
    • J
      nfsd: fix rare symlink decoding bug · 76f47128
      由 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>
      76f47128
  45. 23 6月, 2014 1 次提交
  47. 18 6月, 2014 1 次提交
  49. 07 6月, 2014 2 次提交
  51. 31 5月, 2014 1 次提交