linux-toradex.git/fs/ext4/xattr.c, branch v3.10.45

ext4: fix jbd2 warning under heavy xattr load

2014-05-06T14:55:32+00:00

commit ec4cb1aa2b7bae18dd8164f2e9c7c51abcf61280 upstream.

When heavily exercising xattr code the assertion that
jbd2_journal_dirty_metadata() shouldn't return error was triggered:

WARNING: at /srv/autobuild-ceph/gitbuilder.git/build/fs/jbd2/transaction.c:1237
jbd2_journal_dirty_metadata+0x1ba/0x260()

CPU: 0 PID: 8877 Comm: ceph-osd Tainted: G    W 3.10.0-ceph-00049-g68d04c9 #1
Hardware name: Dell Inc. PowerEdge R410/01V648, BIOS 1.6.3 02/07/2011
 ffffffff81a1d3c8 ffff880214469928 ffffffff816311b0 ffff880214469968
 ffffffff8103fae0 ffff880214469958 ffff880170a9dc30 ffff8802240fbe80
 0000000000000000 ffff88020b366000 ffff8802256e7510 ffff880214469978
Call Trace:
 [] dump_stack+0x19/0x1b
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] jbd2_journal_dirty_metadata+0x1ba/0x260
 [] __ext4_handle_dirty_metadata+0xa3/0x140
 [] ext4_xattr_release_block+0x103/0x1f0
 [] ext4_xattr_block_set+0x1e0/0x910
 [] ext4_xattr_set_handle+0x38b/0x4a0
 [] ? trace_hardirqs_on+0xd/0x10
 [] ext4_xattr_set+0xc2/0x140
 [] ext4_xattr_user_set+0x47/0x50
 [] generic_setxattr+0x6e/0x90
 [] __vfs_setxattr_noperm+0x7b/0x1c0
 [] vfs_setxattr+0xc4/0xd0
 [] setxattr+0x13e/0x1e0
 [] ? __sb_start_write+0xe7/0x1b0
 [] ? mnt_want_write_file+0x28/0x60
 [] ? fget_light+0x3c/0x130
 [] ? mnt_want_write_file+0x28/0x60
 [] ? __mnt_want_write+0x58/0x70
 [] SyS_fsetxattr+0xbe/0x100
 [] system_call_fastpath+0x16/0x1b

The reason for the warning is that buffer_head passed into
jbd2_journal_dirty_metadata() didn't have journal_head attached. This is
caused by the following race of two ext4_xattr_release_block() calls:

CPU1                                CPU2
ext4_xattr_release_block()          ext4_xattr_release_block()
lock_buffer(bh);
/* False */
if (BHDR(bh)->h_refcount == cpu_to_le32(1))
} else {
  le32_add_cpu(&BHDR(bh)->h_refcount, -1);
  unlock_buffer(bh);
                                    lock_buffer(bh);
                                    /* True */
                                    if (BHDR(bh)->h_refcount == cpu_to_le32(1))
                                      get_bh(bh);
                                      ext4_free_blocks()
                                        ...
                                        jbd2_journal_forget()
                                          jbd2_journal_unfile_buffer()
                                          -> JH is gone
  error = ext4_handle_dirty_xattr_block(handle, inode, bh);
  -> triggers the warning

We fix the problem by moving ext4_handle_dirty_xattr_block() under the
buffer lock. Sadly this cannot be done in nojournal mode as that
function can call sync_dirty_buffer() which would deadlock. Luckily in
nojournal mode the race is harmless (we only dirty already freed buffer)
and thus for nojournal mode we leave the dirtying outside of the buffer
lock.

Reported-by: Sage Weil 
Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: avoid bh leak in retry path of ext4_expand_extra_isize_ea()

2013-12-04T18:56:24+00:00

commit dcb9917ba041866686fe152850364826c4622a36 upstream.

Reported-by: Dave Jones 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: fix memory leak in xattr

2013-10-18T14:45:44+00:00

commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.

If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Signed-off-by: Dave Jones 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

ext4: fix miscellaneous big endian warnings

2013-04-10T03:59:55+00:00

None of these result in any bug, but they makes sparse complain.

Signed-off-by: "Theodore Ts'o"

ext4: fix xattr block allocation/release with bigalloc

2013-02-18T17:12:07+00:00

Currently when new xattr block is created or released we we would call
dquot_free_block() or dquot_alloc_block() respectively, among the else
decrementing or incrementing the number of blocks assigned to the
inode by one block.

This however does not work for bigalloc file system because we always
allocate/free the whole cluster so we have to count with that in
dquot_free_block() and dquot_alloc_block() as well.

Use the clusters-to-blocks conversion EXT4_C2B() when passing number of
blocks to the dquot_alloc/free functions to fix the problem.

The problem has been revealed by xfstests #117 (and possibly others).

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Eric Sandeen 
Cc: stable@vger.kernel.org

ext4: fix the number of credits needed for acl ops with inline data

2013-02-09T20:23:03+00:00

Operations which modify extended attributes may need extra journal
credits if inline data is used, since there is a chance that some
extended attributes may need to get pushed to an external attribute
block.

Changes to reflect this was made in xattr.c, but they were missed in
fs/ext4/acl.c.  To fix this, abstract the calculation of the number of
credits needed for xattr operations to an inline function defined in
ext4_jbd2.h, and use it in acl.c and xattr.c.

Also move the function declarations used in inline.c from xattr.h
(where they are non-obviously hidden, and caused problems since
ext4_jbd2.h needs to use the function ext4_has_inline_data), and move
them to ext4.h.

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Tao Ma 
Reviewed-by: Jan Kara

ext4: pass context information to jbd2__journal_start()

2013-02-09T02:59:22+00:00

So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.

The recommended way for finding the longer-running handles is:

   T=/sys/kernel/debug/tracing
   EVENT=$T/events/jbd2/jbd2_handle_stats
   echo "interval > 5" > $EVENT/filter
   echo 1 > $EVENT/enable

   ./run-my-fs-benchmark

   cat $T/trace > /tmp/problem-handles

This will list handles that were active for longer than 20ms.  Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation.  Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:

postmark-2917  [000] ....   196.435786: jbd2_handle_stats: dev 254,32 
   tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
   dirtied_blocks 0

Signed-off-by: "Theodore Ts'o"

ext4: use unlikely to improve the efficiency of the kernel

2013-01-12T21:28:47+00:00

Because the function 'sb_getblk' seldomly fails to return NULL
value,it will be better to use 'unlikely' to optimize it.

Signed-off-by: Wang Shilong 
Signed-off-by: "Theodore Ts'o"

ext4: return ENOMEM if sb_getblk() fails

2013-01-12T21:19:36+00:00

The only reason for sb_getblk() failing is if it can't allocate the
buffer_head.  So ENOMEM is more appropriate than EIO.  In addition,
make sure that the file system is marked as being inconsistent if
sb_getblk() fails.

Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: zero out inline data using memset() instead of empty_zero_page

2012-12-11T08:31:49+00:00

Not all architectures (in particular, sparc64) have empty_zero_page.
So instead of copying from empty_zero_page, use memset to clear the
inline data by signalling to ext4_xattr_set_entry() via a magic
pointer value, EXT4_ZERO_ATTR_VALUE, which is defined by casting -1 to
a pointer.

This fixes a build failure on sparc64, and the memset() should be more
efficient than using memcpy() anyway.

Signed-off-by: Tao Ma 
Signed-off-by: "Theodore Ts'o"