Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751795AbcJCEN7 (ORCPT ); Mon, 3 Oct 2016 00:13:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41006 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884AbcJCENy (ORCPT ); Mon, 3 Oct 2016 00:13:54 -0400 Date: Mon, 3 Oct 2016 06:13:47 +0200 From: Mateusz Guzik To: Pierre Morel Cc: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, farman@linux.vnet.ibm.com, cornelia.huck@de.ibm.com Subject: Re: [PATCH] fs/block_dev.c: always return error in thaw_bdev() Message-ID: <20161003041346.4lvxz4ue3qfhyfpm@mguzik> References: <1440065269-10400-1-git-send-email-pmorel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1440065269-10400-1-git-send-email-pmorel@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 03 Oct 2016 04:13:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1261 Lines: 42 On Thu, Aug 20, 2015 at 12:07:49PM +0200, Pierre Morel wrote: > When triggering thaw-filesystems via magic sysrq, the system enters a > loop in do_thaw_one(), as thaw_bdev() still returns success if > bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return > error (and simplify the code a bit at the same time). > > Reviewed-by: Eric Farman > Reviewed-by: Cornelia Huck > Signed-off-by: Pierre Morel > --- > fs/block_dev.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/fs/block_dev.c b/fs/block_dev.c > index c7e4163..7809c92 100644 > --- a/fs/block_dev.c > +++ b/fs/block_dev.c > @@ -269,14 +269,11 @@ int thaw_bdev(struct block_device *bdev, struct super_block *sb) > error = sb->s_op->thaw_super(sb); > else > error = thaw_super(sb); > - if (error) { > + if (error) > bdev->bd_fsfreeze_count++; > - mutex_unlock(&bdev->bd_fsfreeze_mutex); > - return error; > - } > out: > mutex_unlock(&bdev->bd_fsfreeze_mutex); > - return 0; > + return error; > } > EXPORT_SYMBOL(thaw_bdev); > Apparently this never got in. The bug is still there, reproducible with mere: echo j > /proc/sysrq-trigger -- Mateusz Guzik