Message ID | 20101026011534.0bb7cb64@absol.kitzblitz |
---|---|
State | Accepted, archived |
Headers | show |
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 <nikai@nikai.net> Nice catch, thanks!! I've applied a fix to the ext4 patch queue. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* "Ted Ts'o" <tytso@mit.edu>: > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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 <nikai@nikai.net> --- fs/ext4/super.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-)