This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/wagi/linux-cip-rt.git. The repository failed to update .
Repository mirroring has been paused due to too many failed attempts, and can be resumed by a project maintainer.
Last successful update .
  1. 06 May, 2012 1 commit
  2. 21 Mar, 2012 1 commit
  3. 04 Jan, 2012 2 commits
    • Al Viro's avatar
      switch ->create() to umode_t · 4acdaf27
      Al Viro authored
      vfs_create() ignores everything outside of 16bit subset of its
      mode argument; switching it to umode_t is obviously equivalent
      and it's the only caller of the method
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      4acdaf27
    • Al Viro's avatar
      vfs: fix the stupidity with i_dentry in inode destructors · 6b520e05
      Al Viro authored
      Seeing that just about every destructor got that INIT_LIST_HEAD() copied into
      it, there is no point whatsoever keeping this INIT_LIST_HEAD in inode_init_once();
      the cost of taking it into inode_init_always() will be negligible for pipes
      and sockets and negative for everything else.  Not to mention the removal of
      boilerplate code from ->destroy_inode() instances...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6b520e05
  4. 02 Nov, 2011 1 commit
  5. 28 May, 2011 1 commit
  6. 26 May, 2011 1 commit
  7. 21 Mar, 2011 1 commit
  8. 10 Mar, 2011 1 commit
  9. 07 Jan, 2011 1 commit
    • Nick Piggin's avatar
      fs: icache RCU free inodes · fa0d7e3d
      Nick Piggin authored
      RCU free the struct inode. This will allow:
      
      - Subsequent store-free path walking patch. The inode must be consulted for
        permissions when walking, so an RCU inode reference is a must.
      - sb_inode_list_lock to be moved inside i_lock because sb list walkers who want
        to take i_lock no longer need to take sb_inode_list_lock to walk the list in
        the first place. This will simplify and optimize locking.
      - Could remove some nested trylock loops in dcache code
      - Could potentially simplify things a bit in VM land. Do not need to take the
        page lock to follow page->mapping.
      
      The downsides of this is the performance cost of using RCU. In a simple
      creat/unlink microbenchmark, performance drops by about 10% due to inability to
      reuse cache-hot slab objects. As iterations increase and RCU freeing starts
      kicking over, this increases to about 20%.
      
      In cases where inode lifetimes are longer (ie. many inodes may be allocated
      during the average life span of a single inode), a lot of this cache reuse is
      not applicable, so the regression caused by this patch is smaller.
      
      The cache-hot regression could largely be avoided by using SLAB_DESTROY_BY_RCU,
      however this adds some complexity to list walking and store-free path walking,
      so I prefer to implement this at a later date, if it is shown to be a win in
      real situations. I haven't found a regression in any non-micro benchmark so I
      doubt it will be a problem.
      Signed-off-by: default avatarNick Piggin <npiggin@kernel.dk>
      fa0d7e3d
  10. 29 Oct, 2010 1 commit
  11. 26 Oct, 2010 1 commit
  12. 04 Oct, 2010 2 commits
    • Jan Blunck's avatar
      BKL: Remove BKL from BFS · ba13d597
      Jan Blunck authored
      The BKL is only used in put_super and fill_super that are both protected by
      the superblocks s_umount rw_semaphore. Therefore it is safe to remove the BKL
      entirely.
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ba13d597
    • Jan Blunck's avatar
      BKL: Explicitly add BKL around get_sb/fill_super · db719222
      Jan Blunck authored
      This patch is a preparation necessary to remove the BKL from do_new_mount().
      It explicitly adds calls to lock_kernel()/unlock_kernel() around
      get_sb/fill_super operations for filesystems that still uses the BKL.
      
      I've read through all the code formerly covered by the BKL inside
      do_kern_mount() and have satisfied myself that it doesn't need the BKL
      any more.
      
      do_kern_mount() is already called without the BKL when mounting the rootfs
      and in nfsctl. do_kern_mount() calls vfs_kern_mount(), which is called
      from various places without BKL: simple_pin_fs(), nfs_do_clone_mount()
      through nfs_follow_mountpoint(), afs_mntpt_do_automount() through
      afs_mntpt_follow_link(). Both later functions are actually the filesystems
      follow_link inode operation. vfs_kern_mount() is calling the specified
      get_sb function and lets the filesystem do its job by calling the given
      fill_super function.
      
      Therefore I think it is safe to push down the BKL from the VFS to the
      low-level filesystems get_sb/fill_super operation.
      
      [arnd: do not add the BKL to those file systems that already
             don't use it elsewhere]
      Signed-off-by: default avatarJan Blunck <jblunck@infradead.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Christoph Hellwig <hch@infradead.org>
      db719222
  13. 09 Aug, 2010 3 commits
  14. 28 May, 2010 1 commit
    • Christoph Hellwig's avatar
      rename the generic fsync implementations · 1b061d92
      Christoph Hellwig authored
      We don't name our generic fsync implementations very well currently.
      The no-op implementation for in-memory filesystems currently is called
      simple_sync_file which doesn't make too much sense to start with,
      the the generic one for simple filesystems is called simple_fsync
      which can lead to some confusion.
      
      This patch renames the generic file fsync method to generic_file_fsync
      to match the other generic_file_* routines it is supposed to be used
      with, and the no-op implementation to noop_fsync to make it obvious
      what to expect.  In addition add some documentation for both methods.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      1b061d92
  15. 21 May, 2010 1 commit
  16. 05 Mar, 2010 1 commit
  17. 27 Jan, 2010 1 commit
  18. 12 Jul, 2009 1 commit
  19. 12 Jun, 2009 4 commits
  20. 22 Jan, 2009 1 commit
  21. 06 Jan, 2009 2 commits
  22. 13 Nov, 2008 1 commit
  23. 23 Oct, 2008 1 commit
  24. 13 Sep, 2008 1 commit
    • Eric Sesterhenn's avatar
      bfs: fix Lockdep warning · 1558182f
      Eric Sesterhenn authored
      This fixes:
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.27-rc5-00283-g70bb0896 #68
        ---------------------------------------------
        touch/6855 is trying to acquire lock:
         (&info->bfs_lock){--..}, at: [<c02262f5>] bfs_delete_inode+0x9e/0x18c
      
        but task is already holding lock:
         (&info->bfs_lock){--..}, at: [<c0226c00>] bfs_create+0x45/0x187
      
        other info that might help us debug this:
        2 locks held by touch/6855:
         #0:  (&type->i_mutex_dir_key#5){--..}, at: [<c018ad13>] do_filp_open+0x10b/0x62f
         #1:  (&info->bfs_lock){--..}, at: [<c0226c00>] bfs_create+0x45/0x187
      
        stack backtrace:
        Pid: 6855, comm: touch Not tainted 2.6.27-rc5-00283-g70bb0896 #68
         [<c013e769>] validate_chain+0x458/0x9f4
         [<c013bece>] ? trace_hardirqs_off+0xb/0xd
         [<c013f36b>] __lock_acquire+0x666/0x6e0
         [<c013f440>] lock_acquire+0x5b/0x77
         [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
         [<c06aab74>] mutex_lock_nested+0xbc/0x234
         [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
         [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
         [<c02262f5>] bfs_delete_inode+0x9e/0x18c
         [<c0226257>] ? bfs_delete_inode+0x0/0x18c
         [<c01925e1>] generic_delete_inode+0x94/0xfe
         [<c019265d>] generic_drop_inode+0x12/0x12f
         [<c0191b7e>] iput+0x4b/0x4e
         [<c0226d1e>] bfs_create+0x163/0x187
         [<c0188b42>] vfs_create+0xa6/0x114
         [<c018adb5>] do_filp_open+0x1ad/0x62f
         [<c0107cdc>] ? native_sched_clock+0x82/0x96
         [<c06ac309>] ? _spin_unlock+0x27/0x3c
         [<c019379e>] ? alloc_fd+0xbf/0xc9
         [<c06ae2f4>] ? sub_preempt_count+0x9d/0xab
         [<c019379e>] ? alloc_fd+0xbf/0xc9
         [<c0180391>] do_sys_open+0x42/0xb8
         [<c041d564>] ? trace_hardirqs_on_thunk+0xc/0x10
         [<c0180449>] sys_open+0x1e/0x26
         [<c01038bd>] sysenter_do_call+0x12/0x31
         =======================
      
      The problem is that we don't unlock the bfs->lock mutex before calling
      iput (we do in the other cases).
      Signed-off-by: default avatarEric Sesterhenn <snakebyte@gmx.de>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1558182f
  25. 26 Jul, 2008 3 commits
  26. 30 Apr, 2008 1 commit
  27. 07 Feb, 2008 1 commit
  28. 05 Dec, 2007 1 commit
  29. 15 Nov, 2007 1 commit
  30. 17 Oct, 2007 1 commit