From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932106AbaENLOx (ORCPT ); Wed, 14 May 2014 07:14:53 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49361 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753981AbaENLOv (ORCPT ); Wed, 14 May 2014 07:14:51 -0400 Date: Wed, 14 May 2014 13:14:49 +0200 From: Jan Kara To: Mateusz Guzik Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Josef Bacik , Jan Kara , Al Viro , Eric Sandeen , Joe Perches Subject: Re: [PATCH V2 2/2] fs: print a message when freezing/unfreezing filesystems Message-ID: <20140514111449.GB5824@quack.suse.cz> References: <1400018683-5565-1-git-send-email-mguzik@redhat.com> <1400018683-5565-2-git-send-email-mguzik@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1400018683-5565-2-git-send-email-mguzik@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 14-05-14 00:04:43, Mateusz Guzik wrote: > This helps hang troubleshooting efforts when only dmesg is available. > > While here remove code duplication with MS_RDONLY case and fix a > whitespace nit. I'm somewhat undecided here I have to say. On one hand I don't like printing to kernel log when everything is fine and kernel is operating normally. On the other hand I've seen quite a few cases where people have shot themselves in the foot with filesystem freezing so having some trace of this in the log doesn't seem like a completely bad thing either. What do other people think? Honza > Signed-off-by: Mateusz Guzik > Cc: linux-fsdevel@vger.kernel.org > Cc: Josef Bacik > Cc: Jan Kara > Cc: Al Viro > Cc: Eric Sandeen > Cc: Joe Perches > --- > since v1: > fix copy-pasto which found its way into the patch > restore curly brackets in MS_RDONLY case > fs/super.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/fs/super.c b/fs/super.c > index 017e10a..4dd7356 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -1291,9 +1291,7 @@ int freeze_super(struct super_block *sb) > > if (sb->s_flags & MS_RDONLY) { > /* Nothing to do really... */ > - sb->s_writers.frozen = SB_FREEZE_COMPLETE; > - up_write(&sb->s_umount); > - return 0; > + goto out; > } > > /* From now on, no new normal writers can start */ > @@ -1335,8 +1333,10 @@ int freeze_super(struct super_block *sb) > * This is just for debugging purposes so that fs can warn if it > * sees write activity when frozen is set to SB_FREEZE_COMPLETE. > */ > +out: > sb->s_writers.frozen = SB_FREEZE_COMPLETE; > up_write(&sb->s_umount); > + pr_info("VFS:Filesystem %s frozen\n", sb->s_id); > return 0; > } > EXPORT_SYMBOL(freeze_super); > @@ -1374,7 +1374,7 @@ out: > smp_wmb(); > wake_up(&sb->s_writers.wait_unfrozen); > deactivate_locked_super(sb); > - > + pr_info("VFS:Filesystem %s thawed\n", sb->s_id); > return 0; > } > EXPORT_SYMBOL(thaw_super); > -- > 1.8.3.1 > -- Jan Kara SUSE Labs, CR