1. 09 2月, 2009 10 次提交
  2. 04 2月, 2009 8 次提交
  3. 30 1月, 2009 5 次提交
  4. 29 1月, 2009 6 次提交
  5. 28 1月, 2009 5 次提交
  6. 27 1月, 2009 3 次提交
    • T
      ext4: Fix building with EXT4FS_DEBUG · 9fd9784c
      Thadeu Lima de Souza Cascardo 提交于
      When bg_free_blocks_count was renamed to bg_free_blocks_count_lo in
      560671a0, its uses under EXT4FS_DEBUG were not changed to the helper
      ext4_free_blks_count.
      
      Another commit, 498e5f24, also did not change everything needed under
      EXT4FS_DEBUG, thus making it spill some warnings related to printing
      format.
      
      This commit fixes both issues and makes ext4 build again when
      EXT4FS_DEBUG is enabled.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      9fd9784c
    • T
      ext4: Initialize the new group descriptor when resizing the filesystem · fdff73f0
      Theodore Ts'o 提交于
      Make sure all of the fields of the group descriptor are properly
      initialized.  Previously, we allowed bg_flags field to be contain
      random garbage, which could trigger non-deterministic behavior,
      including a kernel OOPS.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12433Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      fdff73f0
    • V
      inotify: clean up inotify_read and fix locking problems · 3632dee2
      Vegard Nossum 提交于
      If userspace supplies an invalid pointer to a read() of an inotify
      instance, the inotify device's event list mutex is unlocked twice.
      This causes an unbalance which effectively leaves the data structure
      unprotected, and we can trigger oopses by accessing the inotify
      instance from different tasks concurrently.
      
      The best fix (contributed largely by Linus) is a total rewrite
      of the function in question:
      
      On Thu, Jan 22, 2009 at 7:05 AM, Linus Torvalds wrote:
      > The thing to notice is that:
      >
      >  - locking is done in just one place, and there is no question about it
      >   not having an unlock.
      >
      >  - that whole double-while(1)-loop thing is gone.
      >
      >  - use multiple functions to make nesting and error handling sane
      >
      >  - do error testing after doing the things you always need to do, ie do
      >   this:
      >
      >        mutex_lock(..)
      >        ret = function_call();
      >        mutex_unlock(..)
      >
      >        .. test ret here ..
      >
      >   instead of doing conditional exits with unlocking or freeing.
      >
      > So if the code is written in this way, it may still be buggy, but at least
      > it's not buggy because of subtle "forgot to unlock" or "forgot to free"
      > issues.
      >
      > This _always_ unlocks if it locked, and it always frees if it got a
      > non-error kevent.
      
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Cc: Robert Love <rlove@google.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3632dee2
  7. 26 1月, 2009 3 次提交
    • M
      fuse: fix poll notify · f6d47a17
      Miklos Szeredi 提交于
      Move fuse_copy_finish() to before calling fuse_notify_poll_wakeup().
      This is not a big issue because fuse_notify_poll_wakeup() should be
      atomic, but it's cleaner this way, and later uses of notification will
      need to be able to finish the copying before performing some actions.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      f6d47a17
    • M
      fuse: destroy bdi on umount · 26c36791
      Miklos Szeredi 提交于
      If a fuse filesystem is unmounted but the device file descriptor
      remains open and a new mount reuses the old device number, then the
      mount fails with EEXIST and the following warning is printed in the
      kernel log:
      
        WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x35/0x3d()
        sysfs: duplicate filename '0:15' can not be created
      
      The cause is that the bdi belonging to the fuse filesystem was
      destoryed only after the device file was released.  Fix this by
      calling bdi_destroy() from fuse_put_super() instead.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      CC: stable@kernel.org
      26c36791
    • M
      fuse: fuse_fill_super error handling cleanup · c2b8f006
      Miklos Szeredi 提交于
      Clean up error handling for the whole of fuse_fill_super() function.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      c2b8f006