diff options
| author | Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> | 2009-01-05 21:34:30 -0500 |
|---|---|---|
| committer | Theodore Ts'o <tytso@mit.edu> | 2009-01-05 21:34:30 -0500 |
| commit | 032115fcef837a00336ddf7bda584e89789ea498 (patch) | |
| tree | 3c36bca32a6590e675146638992ef988a0fbb430 /fs/jbd2 | |
| parent | fde4d95ad8711c84a36735a17136c45b19746af9 (diff) | |
| download | kernel_samsung_espresso10-032115fcef837a00336ddf7bda584e89789ea498.zip kernel_samsung_espresso10-032115fcef837a00336ddf7bda584e89789ea498.tar.gz kernel_samsung_espresso10-032115fcef837a00336ddf7bda584e89789ea498.tar.bz2 | |
ext4: Don't overwrite allocation_context ac_status
We can call ext4_mb_check_limits even after successfully allocating
the requested blocks. In that case, make sure we don't overwrite
ac_status if it already has the status AC_STATUS_FOUND. This fixes
the lockdep warning:
=============================================
[ INFO: possible recursive locking detected ]
2.6.28-rc6-autokern1 #1
---------------------------------------------
fsstress/11948 is trying to acquire lock:
(&meta_group_info[i]->alloc_sem){----}, at: [<c04d9a49>] ext4_mb_load_buddy+0x9f/0x278
.....
stack backtrace:
.....
[<c04db974>] ext4_mb_regular_allocator+0xbb5/0xd44
.....
but task is already holding lock:
(&meta_group_info[i]->alloc_sem){----}, at: [<c04d9a49>] ext4_mb_load_buddy+0x9f/0x278
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@kernel.org
Diffstat (limited to 'fs/jbd2')
0 files changed, 0 insertions, 0 deletions