1. 10 10月, 2008 2 次提交
  2. 24 9月, 2008 1 次提交
  3. 23 9月, 2008 2 次提交
  4. 07 10月, 2008 1 次提交
  5. 14 9月, 2008 2 次提交
  6. 09 10月, 2008 1 次提交
  7. 14 9月, 2008 1 次提交
  8. 08 9月, 2008 1 次提交
  9. 17 9月, 2008 1 次提交
    • T
      jbd2: clean up how the journal device name is printed · 05496769
      Theodore Ts'o 提交于
      Calculate the journal device name once and stash it away in the
      journal_s structure.  This avoids needing to call bdevname()
      everywhere and reduces stack usage by not needing to allocate an
      on-stack buffer.  In addition, we eliminate the '/' that can appear in
      device names (e.g. "cciss/c0d0p9" --- see kernel bugzilla #11321) that
      can cause problems when creating proc directory names, and include the
      inode number to support ocfs2 which creates multiple journals with
      different inode numbers.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      05496769
  10. 14 9月, 2008 1 次提交
  11. 08 9月, 2008 1 次提交
  12. 09 10月, 2008 1 次提交
    • E
      ext4: Avoid printk floods in the face of directory corruption · 9d9f1775
      Eric Sandeen 提交于
      Note: some people thinks this represents a security bug, since it
      might make the system go away while it is printing a large number of
      console messages, especially if a serial console is involved.  Hence,
      it has been assigned CVE-2008-3528, but it requires that the attacker
      either has physical access to your machine to insert a USB disk with a
      corrupted filesystem image (at which point why not just hit the power
      button), or is otherwise able to convince the system administrator to
      mount an arbitrary filesystem image (at which point why not just
      include a setuid shell or world-writable hard disk device file or some
      such).  Me, I think they're just being silly. --tytso
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-ext4@vger.kernel.org
      Cc: Eugene Teo <eugeneteo@kernel.sg>
      9d9f1775
  13. 14 9月, 2008 2 次提交
  14. 09 9月, 2008 3 次提交
  15. 09 10月, 2008 2 次提交
  16. 10 10月, 2008 1 次提交
  17. 09 9月, 2008 1 次提交
  18. 09 10月, 2008 1 次提交
    • A
      ext4: Make sure all the block allocation paths reserve blocks · a30d542a
      Aneesh Kumar K.V 提交于
      With delayed allocation we need to make sure block are reserved before
      we attempt to allocate them. Otherwise we get block allocation failure
      (ENOSPC) during writepages which cannot be handled. This would mean
      silent data loss (We do a printk stating data will be lost). This patch
      updates the DIO and fallocate code path to do block reservation before
      block allocation. This is needed to make sure parallel DIO and fallocate
      request doesn't take block out of delayed reserve space.
      
      When free blocks count go below a threshold we switch to a slow patch
      which looks at other CPU's accumulated percpu counter values.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a30d542a
  19. 20 8月, 2008 1 次提交
  20. 09 9月, 2008 3 次提交
  21. 10 10月, 2008 2 次提交
  22. 03 10月, 2008 2 次提交
  23. 29 9月, 2008 2 次提交
    • B
      mm owner: fix race between swapoff and exit · 31a78f23
      Balbir Singh 提交于
      There's a race between mm->owner assignment and swapoff, more easily
      seen when task slab poisoning is turned on.  The condition occurs when
      try_to_unuse() runs in parallel with an exiting task.  A similar race
      can occur with callers of get_task_mm(), such as /proc/<pid>/<mmstats>
      or ptrace or page migration.
      
      CPU0                                    CPU1
                                              try_to_unuse
                                              looks at mm = task0->mm
                                              increments mm->mm_users
      task 0 exits
      mm->owner needs to be updated, but no
      new owner is found (mm_users > 1, but
      no other task has task->mm = task0->mm)
      mm_update_next_owner() leaves
                                              mmput(mm) decrements mm->mm_users
      task0 freed
                                              dereferencing mm->owner fails
      
      The fix is to notify the subsystem via mm_owner_changed callback(),
      if no new owner is found, by specifying the new task as NULL.
      
      Jiri Slaby:
      mm->owner was set to NULL prior to calling cgroup_mm_owner_callbacks(), but
      must be set after that, so as not to pass NULL as old owner causing oops.
      
      Daisuke Nishimura:
      mm_update_next_owner() may set mm->owner to NULL, but mem_cgroup_from_task()
      and its callers need to take account of this situation to avoid oops.
      
      Hugh Dickins:
      Lockdep warning and hang below exec_mmap() when testing these patches.
      exit_mm() up_reads mmap_sem before calling mm_update_next_owner(),
      so exec_mmap() now needs to do the same.  And with that repositioning,
      there's now no point in mm_need_new_owner() allowing for NULL mm.
      Reported-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: NDaisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Paul Menage <menage@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      31a78f23
    • L
      Fix NULL pointer dereference in proc_sys_compare · d0185c08
      Linus Torvalds 提交于
      The VFS interface for the 'd_compare()' is a bit special (read: 'odd'),
      because it really just essentially replaces a memcmp().  The filesystem
      is supposed to just compare the two names with whatever case-independent
      or other function.
      
      And when I say 'is supposed to', I obviously mean that 'procfs does odd
      things, and actually looks at the dentry that we don't even pass down,
      rather than just the name'.  Which results in problems, because we
      actually call d_compare before we have even verified that the dentry is
      still hashed at all.
      
      And that causes a problm since the inode that procfs looks at may have
      been free'd and the d_inode pointer is NULL.  procfs just assumes that
      all dentries are positive, since procfs itself never generates a
      negative one.  But memory pressure will still result in the dentry
      getting torn down, and as it is removed by RCU, it still remains visible
      on some lists - and to d_compare.
      
      If the filesystem just did a name comparison, we wouldn't care.  And we
      could just fix procfs to know about negative dentries too.  But rather
      than have the low-level filesystems know about internal VFS details,
      just move the check for a unhashed dentry up a bit, so that we will only
      call d_compare on dentries that are still active.
      
      The actual oops this caused didn't look like a NULL pointer dereference
      because procfs did a 'container_of(inode, struct proc_inode, vfs_inode)'
      to get at its internal proc_inode information from the inode pointer,
      and accessed a field below the inode. So the oops would look something
      like
      
      	BUG: unable to handle kernel paging request at fffffffffffffff0
      	IP: [<ffffffff802bc6c6>] proc_sys_compare+0x36/0x50
      
      and was seen on both x86-64 (Alexey Dobriyan and Hugh Dickins) and
      ppc64 (Hugh Dickins).
      Reported-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Reviewed-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-of-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0185c08
  24. 26 9月, 2008 2 次提交
    • L
      [XFS] Remove xfs_iext_irec_compact_full() · 71a8c87f
      Lachlan McIlroy 提交于
      Yet another bug was found in xfs_iext_irec_compact_full() and while the
      source of the bug was found it wasn't an easy task to track it down
      because the conditions are very difficult to reproduce.
      
      A HUGE thank-you goes to Russell Cattelan and Eric Sandeen for their
      significant effort in tracking down the source of this corruption.
      
      xfs_iext_irec_compact_full() and xfs_iext_irec_compact_pages() are almost
      identical - they both compact indirect extent lists by moving extents from
      subsequent buffers into earlier ones. xfs_iext_irec_compact_pages() only
      moves extents if all of the extents in the next buffer will fit into the
      empty space in the buffer before it. xfs_iext_irec_compact_full() will go
      a step further and move part of the next buffer if all the extents wont
      fit. It will then shift the remaining extents in the next buffer up to the
      start of the buffer. The bug here was that we did not update er_extoff and
      this caused extent list corruption.
      
      It does not appear that this extra functionality gains us much. Calling
      xfs_iext_irec_compact_pages() instead will do a good enough job at
      compacting the indirect list and will be quicker too.
      
      For the case in xfs_iext_indirect_to_direct() the total number of extents
      in the indirect list will fit into one buffer so we will never need the
      extra functionality of xfs_iext_irec_compact_full() there.
      
      Also xfs_iext_irec_compact_pages() doesn't need to do a memmove() (the
      buffers will never overlap) so we don't want the performance hit that can
      incur.
      
      SGI-PV: 987159
      
      SGI-Modid: xfs-linux-melb:xfs-kern:32166a
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      71a8c87f
    • L
      [XFS] Fix extent list corruption in xfs_iext_irec_compact_full(). · f1ccd295
      Lachlan McIlroy 提交于
      If we don't move all the records from the next buffer into the current
      buffer then we need to update the er_extoff field of the next buffer as we
      shift the remaining records to the start of the buffer.
      
      SGI-PV: 987159
      
      SGI-Modid: xfs-linux-melb:xfs-kern:32165a
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NRussell Cattelan <cattelan@thebarn.com>
      f1ccd295
  25. 25 9月, 2008 1 次提交
  26. 18 9月, 2008 1 次提交
  27. 17 9月, 2008 1 次提交