1. 07 1月, 2016 1 次提交
  2. 16 7月, 2011 1 次提交
    • N
      nfsd: Remove deprecated nfsctl system call and related code. · 49b28684
      NeilBrown 提交于
      As promised in feature-removal-schedule.txt it is time to
      remove the nfsctl system call.
      
      Userspace has perferred to not use this call throughout 2.6 and it has been
      excluded in the default configuration since 2.6.36 (9 months ago).
      
      So this patch removes all the code that was being compiled out.
      
      There are still references to sys_nfsctl in various arch systemcall tables
      and related code.  These should be cleaned out too, probably in the next
      merge window.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      49b28684
  3. 25 3月, 2011 1 次提交
    • J
      nfsd: fix auth_domain reference leak on nlm operations · 954032d2
      J. Bruce Fields 提交于
      This was noticed by users who performed more than 2^32 lock operations
      and hence made this counter overflow (eventually leading to
      use-after-free's).  Setting rq_client to NULL here means that it won't
      later get auth_domain_put() when it should be.
      
      Appears to have been introduced in 2.5.42 by "[PATCH] kNFSd: Move auth
      domain lookup into svcauth" which moved most of the rq_client handling
      to common svcauth code, but left behind this one line.
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      954032d2
  4. 16 12月, 2009 1 次提交
  5. 15 12月, 2009 2 次提交
  6. 14 11月, 2009 1 次提交
  7. 04 10月, 2008 1 次提交
    • J
      nfsd: common grace period control · af558e33
      J. Bruce Fields 提交于
      Rewrite grace period code to unify management of grace period across
      lockd and nfsd.  The current code has lockd and nfsd cooperate to
      compute a grace period which is satisfactory to them both, and then
      individually enforce it.  This creates a slight race condition, since
      the enforcement is not coordinated.  It's also more complicated than
      necessary.
      
      Here instead we have lockd and nfsd each inform common code when they
      enter the grace period, and when they're ready to leave the grace
      period, and allow normal locking only after both of them are ready to
      leave.
      
      We also expect the locks_start_grace()/locks_end_grace() interface here
      to be simpler to build on for future cluster/high-availability work,
      which may require (for example) putting individual filesystems into
      grace, or enforcing grace periods across multiple cluster nodes.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      af558e33
  8. 26 7月, 2008 1 次提交
  9. 24 6月, 2008 1 次提交
  10. 18 7月, 2007 1 次提交
  11. 14 12月, 2006 1 次提交
  12. 21 10月, 2006 1 次提交
  13. 17 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: Allow lockd to drop replies as appropriate · d343fce1
      NeilBrown 提交于
      It is possible for the ->fopen callback from lockd into nfsd to find that an
      answer cannot be given straight away (an upcall is needed) and so the request
      has to be 'dropped', to be retried later.  That error status is not currently
      propagated back.
      
      So:
        Change nlm_fopen to return nlm error codes (rather than a private
        protocol) and define a new nlm_drop_reply code.
        Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply
        when this error comes back.
        Cause svc_process to drop a request which returns a status of
        rpc_drop_reply.
      
      [akpm@osdl.org: fix warning storm]
      Cc: Marc Eshel <eshel@almaden.ibm.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d343fce1
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4