Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 2月, 2007 1 次提交
  3. 21 10月, 2006 2 次提交
  5. 23 9月, 2006 4 次提交
  7. 25 8月, 2006 1 次提交
    • D
      NFS: Check lengths more thoroughly in NFS4 readdir XDR decode · e8896495
      由 David Howells 提交于 
      Check the bounds of length specifiers more thoroughly in the XDR decoding of
NFS4 readdir reply data.

Currently, if the server returns a bitmap or attr length that causes the
current decode point pointer to wrap, this could go undetected (consider a
small "negative" length on a 32-bit machine).

Also add a check into the main XDR decode handler to make sure that the amount
of data is a multiple of four bytes (as specified by RFC-1014).  This makes
sure that we can do u32* pointer subtraction in the NFS client without risking
an undefined result (the result is undefined if the pointers are not correctly
aligned with respect to one another).
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
(cherry picked from 5861fddd64a7eaf7e8b1a9997455a24e7f688092 commit)
      e8896495
  9. 09 6月, 2006 7 次提交
  11. 24 3月, 2006 1 次提交
  13. 21 3月, 2006 1 次提交
  15. 07 1月, 2006 7 次提交
  17. 28 10月, 2005 8 次提交
  19. 19 10月, 2005 5 次提交
    • J
      NFSv4: handle no acl attr · 8c233cf9
      由 J. Bruce Fields 提交于 
       Stop handing garbage to userspace in the case where a weird server clears the
 acl bit in the getattr return (despite the fact that they've already claimed
 acl support.)
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      8c233cf9
    • T
      NFSv4: Fix up handling of open_to_lock sequence ids · 06735b34
      由 Trond Myklebust 提交于 
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      06735b34
    • T
      NFSv4: Make NFS clean up byte range locks asynchronously · faf5f49c
      由 Trond Myklebust 提交于 
       Currently we fail to do so if the process was signalled.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      faf5f49c
    • T
      NFSv4: Fix a potential CLOSE race · 9512135d
      由 Trond Myklebust 提交于 
       Once the state_owner and lock_owner semaphores get removed, it will be
 possible for other OPEN requests to reopen the same file if they have
 lower sequence ids than our CLOSE call.
 This patch ensures that we recheck the file state once
 nfs_wait_on_sequence() has completed waiting.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      9512135d
    • T
      NFSv4: Add functions to order RPC calls · cee54fc9
      由 Trond Myklebust 提交于 
       NFSv4 file state-changing functions such as OPEN, CLOSE, LOCK,... are all
 labelled with "sequence identifiers" in order to prevent the server from
 reordering RPC requests, as this could cause its file state to
 become out of sync with the client.

 Currently the NFS client code enforces this ordering locally using
 semaphores to restrict access to structures until the RPC call is done.
 This, of course, only works with synchronous RPC calls, since the
 user process must first grab the semaphore.
 By dropping semaphores, and instead teaching the RPC engine to hold
 the RPC calls until they are ready to be sent, we can extend this
 process to work nicely with asynchronous RPC calls too.

 This patch adds a new list called "rpc_sequence" that defines the order
 of the RPC calls to be sent. We add one such list for each state_owner.
 When an RPC call is ready to be sent, it checks if it is top of the
 rpc_sequence list. If so, it proceeds. If not, it goes back to sleep,
 and loops until it hits top of the list.
 Once the RPC call has completed, it can then bump the sequence id counter,
 and remove itself from the rpc_sequence list, and then wake up the next
 sleeper.

 Note that the state_owner sequence ids and lock_owner sequence ids are
 all indexed to the same rpc_sequence list, so OPEN, LOCK,... requests
 are all ordered w.r.t. each other.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      cee54fc9
  21. 23 6月, 2005 3 次提交