linux-toradex.git/fs/ext3/xattr.c, branch v2.6.28.4

ext3/4: fix uninitialized bs in ext3/4_xattr_set_handle()

2008-05-15T02:11:14+00:00

This fix the uninitialized bs when we try to replace a xattr entry in
ibody with the new value which require more than free space.

This situation only happens we format ext3/4 with inode size more than 128 and
we have put xattr entries both in ibody and block.  The consequences about
this bug is we will lost the xattr block which pointed by i_file_acl with all
xattr entires in it.  We will alloc a new xattr block and put that large value
entry in it.  The old xattr block will become orphan block.

Signed-off-by: Tiger Yang 
Cc: 
Cc: Andreas Gruenbacher 
Acked-by: Andreas Dilger 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ext3: replace remaining FUNCTION occurrences

2008-04-28T15:58:45+00:00

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ext3: use ext3_group_first_block_no()

2008-04-28T15:58:44+00:00

Use ext3_group_first_block_no()

Signed-off-by: Akinobu Mita 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

make ext3_xattr_list() static

2008-04-28T15:58:44+00:00

Make the needlessly global ext3_xattr_list() static.

Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vfs: fix possible deadlock in ext2, ext3, ext4 when using xattrs

2008-04-16T02:35:41+00:00

mb_cache_entry_alloc() was allocating cache entries with GFP_KERNEL.  But
filesystems are calling this function while holding xattr_sem so possible
recursion into the fs violates locking ordering of xattr_sem and transaction
start / i_mutex for ext2-4.  Change mb_cache_entry_alloc() so that filesystems
can specify desired gfp mask and use GFP_NOFS from all of them.

Signed-off-by: Jan Kara 
Reported-by: Dave Jones 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ext3: fix wrong gfp type under transaction

2008-03-20T01:53:36+00:00

There are several places where we make allocations with GFP_KERNEL while under
a transaction, which could lead to an assertion panic or lockup if under
memory pressure.  This patch switches these problem areas to use GFP_NOFS to
keep these problems from happening.

Signed-off-by: Josef Bacik 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ext3: replace all adds to little endians variables with le*_add_cpu

2008-02-08T17:22:32+00:00

replace all:
	little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
				expression_in_cpu_byteorder);
with:
	leX_add_cpu(&little_endian_variable, expression_in_cpu_byteorder);
sparse didn't generate any new warning with this patch

Signed-off-by: Marcin Slusarz 
Cc: Mark Fasheh 
Cc: David Chinner 
Cc: Timothy Shimmin 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

JBD/ext3 cleanups: convert to kzalloc

2007-10-19T18:53:34+00:00

Convert kmalloc to kzalloc() and get rid of the memset().

Signed-off-by: Mingming Cao 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] "ext[34]: EA block reference count racing fix" performance fix

2007-03-23T18:01:22+00:00

A little mistake in 8a2bfdcbfa441d8b0e5cb9c9a7f45f77f80da465 is making all
transactions synchronous, which reduces ext3 performance to comical levels.

Cc: Mingming Cao 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] ext[34]: EA block reference count racing fix

2007-03-01T22:53:38+00:00

There are race issues around ext[34] xattr block release code.

ext[34]_xattr_release_block() checks the reference count of xattr block
(h_refcount) and frees that xattr block if it is the last one reference it.
 Unlike ext2, the check of this counter is unprotected by any lock.
ext[34]_xattr_release_block() will free the mb_cache entry before freeing
that xattr block.  There is a small window between the check for the re
h_refcount ==1 and the call to mb_cache_entry_free().  During this small
window another inode might find this xattr block from the mbcache and reuse
it, racing a refcount updates.  The xattr block will later be freed by the
first inode without notice other inode is still use it.  Later if that
block is reallocated as a datablock for other file, then more serious
problem might happen.

We need put a lock around places checking the refount as well to avoid
racing issue.  Another place need this kind of protection is in
ext3_xattr_block_set(), where it will modify the xattr block content in-
the-fly if the refcount is 1 (means it's the only inode reference it).

This will also fix another issue: the xattr block may not get freed at all
if no lock is to protect the refcount check at the release time.  It is
possible that the last two inodes could release the shared xattr block at
the same time.  But both of them think they are not the last one so only
decreased the h_refcount without freeing xattr block at all.

We need to call lock_buffer() after ext3_journal_get_write_access() to
avoid deadlock (because the later will call lock_buffer()/unlock_buffer
() as well).

Signed-off-by: Mingming Cao 
Cc: Andreas Gruenbacher 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds