1. 21 10月, 2006 8 次提交
  2. 17 10月, 2006 4 次提交
  3. 06 10月, 2006 1 次提交
    • N
      [PATCH] knfsd: tidy up up meaning of 'buffer size' in nfsd/sunrpc · c6b0a9f8
      NeilBrown 提交于
      There is some confusion about the meaning of 'bufsz' for a sunrpc server.
      In some cases it is the largest message that can be sent or received.  In
      other cases it is the largest 'payload' that can be included in a NFS
      message.
      
      In either case, it is not possible for both the request and the reply to be
      this large.  One of the request or reply may only be one page long, which
      fits nicely with NFS.
      
      So we remove 'bufsz' and replace it with two numbers: 'max_payload' and
      'max_mesg'.  Max_payload is the size that the server requests.  It is used
      by the server to check the max size allowed on a particular connection:
      depending on the protocol a lower limit might be used.
      
      max_mesg is the largest single message that can be sent or received.  It is
      calculated as the max_payload, rounded up to a multiple of PAGE_SIZE, and
      with PAGE_SIZE added to overhead.  Only one of the request and reply may be
      this size.  The other must be at most one page.
      
      Cc: Greg Banks <gnb@sgi.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c6b0a9f8
  4. 04 10月, 2006 23 次提交
  5. 03 10月, 2006 1 次提交
    • D
      [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers · afefdbb2
      David Howells 提交于
      These patches make the kernel pass 64-bit inode numbers internally when
      communicating to userspace, even on a 32-bit system.  They are required
      because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
      for example.  The 64-bit inode numbers are then propagated to userspace
      automatically where the arch supports it.
      
      Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
      number returned by stat64() or getdents64() to differentiate files, and
      failing because the 64-bit inode number space was compressed to 32-bits, and
      so overlaps occur.
      
      This patch:
      
      Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
      inode number so that 64-bit inode numbers can be passed back to userspace.
      
      The stat functions then returns the full 64-bit inode number where
      available and where possible.  If it is not possible to represent the inode
      number supplied by the filesystem in the field provided by userspace, then
      error EOVERFLOW will be issued.
      
      Similarly, the getdents/readdir functions now pass the full 64-bit inode
      number to userspace where possible, returning EOVERFLOW instead when a
      directory entry is encountered that can't be properly represented.
      
      Note that this means that some inodes will not be stat'able on a 32-bit
      system with old libraries where they were before - but it does mean that
      there will be no ambiguity over what a 32-bit inode number refers to.
      
      Note similarly that directory scans may be cut short with an error on a
      32-bit system with old libraries where the scan would work before for the
      same reasons.
      
      It is judged unlikely that this situation will occur because modern glibc
      uses 64-bit capable versions of stat and getdents class functions
      exclusively, and that older systems are unlikely to encounter
      unrepresentable inode numbers anyway.
      
      [akpm: alpha build fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      afefdbb2
  6. 02 10月, 2006 3 次提交
    • P
      [PATCH] nfsd: lockdep annotation · 12fd3520
      Peter Zijlstra 提交于
      while doing a kernel make modules_install install over an NFS mount.
      
        =============================================
        [ INFO: possible recursive locking detected ]
        ---------------------------------------------
        nfsd/9550 is trying to acquire lock:
         (&inode->i_mutex){--..}, at: [<c034c845>] mutex_lock+0x1c/0x1f
      
        but task is already holding lock:
         (&inode->i_mutex){--..}, at: [<c034c845>] mutex_lock+0x1c/0x1f
      
        other info that might help us debug this:
        2 locks held by nfsd/9550:
         #0:  (hash_sem){..--}, at: [<cc895223>] exp_readlock+0xd/0xf [nfsd]
         #1:  (&inode->i_mutex){--..}, at: [<c034c845>] mutex_lock+0x1c/0x1f
      
        stack backtrace:
         [<c0103508>] show_trace_log_lvl+0x58/0x152
         [<c0103b8b>] show_trace+0xd/0x10
         [<c0103c2f>] dump_stack+0x19/0x1b
         [<c012aa57>] __lock_acquire+0x77a/0x9a3
         [<c012af4a>] lock_acquire+0x60/0x80
         [<c034c6c2>] __mutex_lock_slowpath+0xa7/0x20e
         [<c034c845>] mutex_lock+0x1c/0x1f
         [<c0162edc>] vfs_unlink+0x34/0x8a
         [<cc891d98>] nfsd_unlink+0x18f/0x1e2 [nfsd]
         [<cc89884f>] nfsd3_proc_remove+0x95/0xa2 [nfsd]
         [<cc88f0d4>] nfsd_dispatch+0xc0/0x178 [nfsd]
         [<c033e84d>] svc_process+0x3a5/0x5ed
         [<cc88f5ba>] nfsd+0x1a7/0x305 [nfsd]
         [<c0101005>] kernel_thread_helper+0x5/0xb
        DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
        Leftover inexact backtrace:
         [<c0103b8b>] show_trace+0xd/0x10
         [<c0103c2f>] dump_stack+0x19/0x1b
         [<c012aa57>] __lock_acquire+0x77a/0x9a3
         [<c012af4a>] lock_acquire+0x60/0x80
         [<c034c6c2>] __mutex_lock_slowpath+0xa7/0x20e
         [<c034c845>] mutex_lock+0x1c/0x1f
         [<c0162edc>] vfs_unlink+0x34/0x8a
         [<cc891d98>] nfsd_unlink+0x18f/0x1e2 [nfsd]
         [<cc89884f>] nfsd3_proc_remove+0x95/0xa2 [nfsd]
         [<cc88f0d4>] nfsd_dispatch+0xc0/0x178 [nfsd]
         [<c033e84d>] svc_process+0x3a5/0x5ed
         [<cc88f5ba>] nfsd+0x1a7/0x305 [nfsd]
         [<c0101005>] kernel_thread_helper+0x5/0xb
      
        =============================================
        [ INFO: possible recursive locking detected ]
        ---------------------------------------------
        nfsd/9580 is trying to acquire lock:
         (&inode->i_mutex){--..}, at: [<c034cc1d>] mutex_lock+0x1c/0x1f
      
        but task is already holding lock:
         (&inode->i_mutex){--..}, at: [<c034cc1d>] mutex_lock+0x1c/0x1f
      
        other info that might help us debug this:
        2 locks held by nfsd/9580:
         #0:  (hash_sem){..--}, at: [<cc89522b>] exp_readlock+0xd/0xf [nfsd]
         #1:  (&inode->i_mutex){--..}, at: [<c034cc1d>] mutex_lock+0x1c/0x1f
      
        stack backtrace:
         [<c0103508>] show_trace_log_lvl+0x58/0x152
         [<c0103b8b>] show_trace+0xd/0x10
         [<c0103c2f>] dump_stack+0x19/0x1b
         [<c012aa63>] __lock_acquire+0x77a/0x9a3
         [<c012af56>] lock_acquire+0x60/0x80
         [<c034ca9a>] __mutex_lock_slowpath+0xa7/0x20e
         [<c034cc1d>] mutex_lock+0x1c/0x1f
         [<cc892ad1>] nfsd_setattr+0x2c8/0x499 [nfsd]
         [<cc893ede>] nfsd_create_v3+0x31b/0x4ac [nfsd]
         [<cc8984a1>] nfsd3_proc_create+0x128/0x138 [nfsd]
         [<cc88f0d4>] nfsd_dispatch+0xc0/0x178 [nfsd]
         [<c033ec1d>] svc_process+0x3a5/0x5ed
         [<cc88f5ba>] nfsd+0x1a7/0x305 [nfsd]
         [<c0101005>] kernel_thread_helper+0x5/0xb
        DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
        Leftover inexact backtrace:
         [<c0103b8b>] show_trace+0xd/0x10
         [<c0103c2f>] dump_stack+0x19/0x1b
         [<c012aa63>] __lock_acquire+0x77a/0x9a3
         [<c012af56>] lock_acquire+0x60/0x80
         [<c034ca9a>] __mutex_lock_slowpath+0xa7/0x20e
         [<c034cc1d>] mutex_lock+0x1c/0x1f
         [<cc892ad1>] nfsd_setattr+0x2c8/0x499 [nfsd]
         [<cc893ede>] nfsd_create_v3+0x31b/0x4ac [nfsd]
         [<cc8984a1>] nfsd3_proc_create+0x128/0x138 [nfsd]
         [<cc88f0d4>] nfsd_dispatch+0xc0/0x178 [nfsd]
         [<c033ec1d>] svc_process+0x3a5/0x5ed
         [<cc88f5ba>] nfsd+0x1a7/0x305 [nfsd]
         [<c0101005>] kernel_thread_helper+0x5/0xb
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      12fd3520
    • G
      [PATCH] knfsd: allow admin to set nthreads per node · eed2965a
      Greg Banks 提交于
      Add /proc/fs/nfsd/pool_threads which allows the sysadmin (or a userspace
      daemon) to read and change the number of nfsd threads in each pool.  The
      format is a list of space-separated integers, one per pool.
      Signed-off-by: NGreg Banks <gnb@melbourne.sgi.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>
      eed2965a
    • G
      [PATCH] knfsd: use svc_set_num_threads to manage threads in knfsd · eec09661
      Greg Banks 提交于
      Replace the existing list of all nfsd threads with new code using
      svc_create_pooled().
      Signed-off-by: NGreg Banks <gnb@melbourne.sgi.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>
      eec09661