1. 30 1月, 2008 7 次提交
  2. 12 12月, 2007 1 次提交
    • T
      NFSv2/v3: Fix a memory leak when using -onolock · 5cef338b
      Trond Myklebust 提交于
      Neil Brown said:
      > Hi Trond,
      > 
      > We found that a machine which made moderately heavy use of
      > 'automount' was leaking some nfs data structures - particularly the
      > 4K allocated by rpc_alloc_iostats.
      > It turns out that this only happens with filesystems with -onolock
      > set.
      
      > The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
      > set server->destroy, so when the filesystem is unmounted, the
      > ->client_acl is not shutdown, and so several resources are still
      > held.  Multiple mount/umount cycles will slowly eat away memory
      > several pages at a time.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NNeilBrown <neilb@suse.de>
      5cef338b
  3. 17 10月, 2007 1 次提交
  4. 10 10月, 2007 4 次提交
  5. 29 9月, 2007 1 次提交
  6. 17 7月, 2007 1 次提交
  7. 11 7月, 2007 3 次提交
  8. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  9. 09 5月, 2007 1 次提交
  10. 01 5月, 2007 1 次提交
  11. 13 2月, 2007 2 次提交
  12. 04 2月, 2007 1 次提交
  13. 22 11月, 2006 2 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells 提交于
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
    • D
      WorkStruct: Separate delayable and non-delayable events. · 52bad64d
      David Howells 提交于
      Separate delayable work items from non-delayable work items be splitting them
      into a separate structure (delayed_work), which incorporates a work_struct and
      the timer_list removed from work_struct.
      
      The work_struct struct is huge, and this limits it's usefulness.  On a 64-bit
      architecture it's nearly 100 bytes in size.  This reduces that by half for the
      non-delayable type of event.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      52bad64d
  14. 21 10月, 2006 2 次提交
  15. 09 10月, 2006 3 次提交
  16. 04 10月, 2006 1 次提交
  17. 02 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: be more selective in which sockets lockd listens on · 24e36663
      NeilBrown 提交于
      Currently lockd listens on UDP always, and TCP if CONFIG_NFSD_TCP is set.
      
      However as lockd performs services of the client as well, this is a problem.
      If CONFIG_NfSD_TCP is not set, and a tcp mount is used, the server will not be
      able to call back to lockd.
      
      So:
       - add an option to lockd_up saying which protocol is needed
       - Always open sockets for which an explicit port was given, otherwise
         only open a socket of the type required
       - Change nfsd to do one lockd_up per socket rather than one per thread.
      
      This
       - removes the dependancy on CONFIG_NFSD_TCP
       - means that lockd may open sockets other than at startup
       - means that lockd will *not* listen on UDP if the only
         mounts are TCP mount (and nfsd hasn't started).
      
      The latter is the only one that concerns me at all - I don't know if this
      might be a problem with some servers.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      24e36663
  18. 23 9月, 2006 7 次提交