Although the mutex isn't locked yet, if ext4_li_request_new
fails, the mutex would get unlocked on the error path.
Signed-off-by: Nicolas Kaiser <[email protected]>
---
fs/ext4/super.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index d0c3328..8bca022 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2915,10 +2915,8 @@ static int ext4_register_li_request(struct super_block *sb,
}
elr = ext4_li_request_new(sb, first_not_zeroed);
- if (!elr) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!elr)
+ return -ENOMEM;
mutex_lock(&ext4_li_mtx);
--
1.7.2.2
On Tue, Oct 26, 2010 at 01:15:34AM +0200, Nicolas Kaiser wrote:
> Although the mutex isn't locked yet, if ext4_li_request_new
> fails, the mutex would get unlocked on the error path.
>
> Signed-off-by: Nicolas Kaiser <[email protected]>
Nice catch, thanks!! I've applied a fix to the ext4 patch queue.
- Ted
* "Ted Ts'o" <[email protected]>:
> On Tue, Oct 26, 2010 at 01:15:34AM +0200, Nicolas Kaiser wrote:
> > Although the mutex isn't locked yet, if ext4_li_request_new
> > fails, the mutex would get unlocked on the error path.
> Nice catch, thanks!! I've applied a fix to the ext4 patch queue.
Thanks for augmenting the patch - looks good to me :)
Best regards,
Nicolas Kaiser