Fix possible false assertion failure in log_do_checkpoint(). We might fail
to detect that we actually made a progress when cleaning up the checkpoint
lists if we don't retry after writing something to disk. The patch was
confirmed to fix observed assertion failures for several users.
When we flushed some buffers we need to retry scanning the list.
Otherwise we can fail to detect our progress.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the leak of sb->s_fs_info in both the HFS and HFS+
modules. In addition to this, it fixes an oops happening when trying to
mount a non-hfsplus filesystem using hfsplus. This patch is from Roman
Zippel, based off patches sent by myself. It's been included in 2.6.12-
rc4. See
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=945b092011c6af71a0107be96e119c8c08776f3f
(chrisw: backport to -stable)
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Colin Leroy <colin@colino.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/hfs/mdb.c | 5 +++++
fs/hfs/super.c | 8 +++-----
fs/hfsplus/super.c | 6 +++++-
3 files changed, 13 insertions(+), 6 deletions(-)
This patch fixed a race between ext3_discard_reservation() and
ext3_try_to_allocate_with_rsv().
There is a window where ext3_discard_reservation will remove an already
unlinked reservation window node from the filesystem reservation tree:
It thinks the reservation is still linked in the filesystem reservation
tree, but it is actually temperately removed from the tree by
allocate_new_reservation() when it failed to make a new reservation from
the current group and try to make a new reservation from next block
group.
Here is how it could happen:
CPU 1
try to allocate a block in group1 with given reservation window my_rsv
ext3_try_to_allocate_with_rsv(group
----copy reservation window my_rsv into local rsv_copy
ext3_try_to_allocate(...rsv_copy)
----no free block in existing reservation window,
----need a new reservation window
spin_lock(&rsv_lock);
CPU 2
ext3_discard_reservation
if (!rsv_is_empty()
----this is true
spin_lock(&rsv_lock)
----waiting for thread 1
CPU 1:
allocate_new_reservation
failed to reserve blocks in this group
remove the window from the tree
rsv_window_remove(my_rsv)
----window node is unlinked from the tree here
return -1
spin_unlock(&rsv_lock)
ext3_try_to_allocate_with_rsv() failed in this group
group++
CPU 2
spin_lock(&rsv_lock) succeed
rsv_remove_window ()
---------------break, trying to remove a unlinked node from the tree
....
CPU 1:
ext3_try_to_allocate_with_rsv(group, my_rsv)
rsv_is_empty is true, need a new reservation window
spin_lock(&rsv_lock);
^--------------- spinning forever
We need to re-check whether the reservation window is still linked to
the tree after grab the rsv_lock spin lock in ext3_discard_reservation,
to prevent panic in rsv_remove_window->rb_erase.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Revert the msdos.c patch as it causes more problems than it helps right now.
(it got munged together with the i2c patch also, stupid scripts...)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Subject: Prevent race condition in jbd
This patch from Stephen Tweedie which fixes a race in jbd code (it
demonstrated itself as more or less random NULL dereferences in the
journal code).
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Chris Mason <mason@suse.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yichen Xie <yxie@cs.stanford.edu> points out that load_elf_library can
modify `elf_phdata' before freeing it.
CAN-2005-0749 is assigned to this issue.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
I think I have discovered a potential security problem in ext2: when a
new directory is created, the ext2 block written to disk is not
initialized.
Included is a proposed patch for Linux 2.6 (ext2_make_empty() function):
CAN-2005-0400 is assigned to this issue.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Michal Zalewski <lcamtuf@dione.ids.pl> discovers range checking flaws in
iso9660 filesystem.
http://marc.theaimsgroup.com/?l=bugtraq&m=111110067304783&w=2
CAN-2005-0815 is assigned to this issue.
Some more defensive checks to keep corrupt isofs images from corrupting
memory or causing Oops.
Signed-off-by: Chris Wright <chrisw@osdl.org>
===== fs/isofs/rock.c 1.23 vs edited =====
Michal Zalewski <lcamtuf@dione.ids.pl> discovers range checking flaws in
iso9660 filesystem.
http://marc.theaimsgroup.com/?l=bugtraq&m=111110067304783&w=2
CAN-2005-0815 is assigned to this issue.
From: Linus Torvalds <torvalds@osdl.org>
isofs: more "corrupted iso image" error cases
Thanks to Michal Zalewski for testing.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Michal Zalewski <lcamtuf@dione.ids.pl> discovers range checking flaws in
iso9660 filesystem.
http://marc.theaimsgroup.com/?l=bugtraq&m=111110067304783&w=2
CAN-2005-0815 is assigned to this issue.
From: Linus Torvalds <torvalds@osdl.org>
isofs: Handle corupted rock-ridge info slightly better.
Keyword here being 'slightly'. The code is a mess.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Set_task_comm uses strlcpy, so get_task_comm must use strncpy.
Signed-Off-by: Prasanna Meda <pmeda@akamai.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This makes du(1) output completely wrong.
Signed-off-by: Eric Lammerts <eric@lammerts.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
