Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 7月, 2008 1 次提交
  3. 17 5月, 2008 1 次提交
  5. 29 4月, 2008 2 次提交
  7. 20 4月, 2008 1 次提交
  9. 20 3月, 2008 2 次提交
    • C
      NFS: Save the values of the "mount*=" mount options · 3f8400d1
      由 Chuck Lever 提交于 
      Save the value of the mountproto= mountport= mountvers= and mountaddr=
options so that these values can be displayed later via
nfs_show_options().

This preserves the intent of the original mount options, should the file
system need to be remounted based on what's displayed in /proc/mounts.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      3f8400d1
    • C
      NFS: Save the value of the "port=" mount option · f22d6d79
      由 Chuck Lever 提交于 
      During a remount based on the mount options displayed in /proc/mounts, we
want to preserve the original behavior of the mount request.  Let's save
the original setting of the "port=" mount option in the mount's nfs_server
structure.

This allows us to simplify the default behavior of port setting for NFSv4
mounts: by default, NFSv2/3 mounts first try an RPC bind to determine the
NFS server's port, unless the user specified the "port=" mount option;
Users can force the client to skip the RPC bind by explicitly specifying
"port=<value>".

NFSv4, by contrast, assumes the NFS server port is 2049 and skips the RPC
bind, unless the user specifies "port=".  Users can force an RPC bind for
NFSv4 by explicitly specifying "port=0".

I added a couple of extra comments to clarify this behavior.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f22d6d79
  11. 29 2月, 2008 1 次提交
  13. 30 1月, 2008 19 次提交
  15. 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
  17. 07 12月, 2007 1 次提交
  19. 17 10月, 2007 1 次提交
  21. 10 10月, 2007 4 次提交
  23. 29 9月, 2007 1 次提交
  25. 17 7月, 2007 1 次提交
  27. 11 7月, 2007 3 次提交
  29. 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