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>
cmm@us.ibm.com