All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Américo Wang" <xiyou.wangcong@gmail.com>
To: Jianjun Kong <jianjun@zeuux.org>
Cc: Tim Shimmin <tes@sgi.com>,
	stable@kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] XFS fix remount rw with unrecognized options
Date: Thu, 16 Oct 2008 14:59:26 +0100	[thread overview]
Message-ID: <20081016135926.GC13374@hack.voiplan.pt> (raw)
In-Reply-To: <20081016134112.GA8773@ubuntu>

On Thu, Oct 16, 2008 at 09:41:12PM +0800, Jianjun Kong wrote:
>On Thu, Oct 16, 2008 at 11:29:26AM +1100, Tim Shimmin wrote:
>>Resending as I mangled sending the mail from home last time. Sorry.
>>
>>Please include the following patch for 2.6.27.1 stable release as
>>suggested by Christoph Hellwig and Eric Sandeen.
>>It fixes a regression in the recent remount recoding
>>where remounting say from ro to rw allows the xfs flags to
>>be out of sync with the vfs flags, resulting
>>in failures for some programs such as touch (which end up calling xfs_setattr).
>>The fix is a very minor and clear.
>>
>>Thanks,
>>Tim.
>>
>>Date: Sun, 12 Oct 2008 14:30:44 +0200
>>From: Christoph Hellwig <hch@lst.de>
>>To: xfs@oss.sgi.com
>>Subject: [PATCH] fix remount rw with unrecognized options
>>
>>When we skip unrecognized options in xfs_fs_remount we should just break
>>out of the switch and not return because otherwise we may skip clearing
>>the xfs-internal read-only flag.  This will only show up on some
>>operations like touch because most read-only checks are done by the VFS
>>which thinks this filesystem is r/w.  Eventually we should replace the
>>XFS read-only flag with a helper that always checks the VFS flag to make
>>sure they can never get out of sync.
>>
>>Bug reported and fix verified by Marcel Beister on #xfs.
>>Bug fix verified by updated xfstests/189.
>>
>>Signed-off-by: Christoph Hellwig <hch@lst.de>
>>Acked-by: Eric Sandeen <sandeen@sandeen.net>
>>Signed-off-by: Timothy Shimmin <tes@sgi.com>
>>
>>Index: mainline/fs/xfs/linux-2.6/xfs_super.c
>>===================================================================
>>--- mainline.orig/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:26.542652847 +1100
>>+++ mainline/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:45.376217172 +1100
>>@@ -1323,7 +1323,7 @@ xfs_fs_remount(
>> 	"XFS: mount option \"%s\" not supported for remount\n", p);
>> 			return -EINVAL;
>> #else
>>-			return 0;
>>+			break;
>> #endif
>> 		}
>> 	}
>
>
>And the code above "return 0" can not be executed, so delete them.


return 0; is in the removed part... so it's already removed.


>__________________________________________
>#if 0
>                        printk(KERN_INFO
>        "XFS: mount option \"%s\" not supported for remount\n", p);
>                        return -EINVAL;
>#else                                                                                                            
>                        return 0;
>-----------------------------------------
>
>
>Signed-off-by: Jianjun Kong <kongjianjun@gmail.com>
>---
> fs/xfs/linux-2.6/xfs_super.c |    7 +------
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
>diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c
>index e390136..bd5ec81 100644
>--- a/fs/xfs/linux-2.6/xfs_super.c
>+++ b/fs/xfs/linux-2.6/xfs_super.c
>@@ -1318,12 +1318,7 @@ xfs_fs_remount(
> 			 * every remount request, and silently ignore all
> 			 * options that we can't actually change.
> 			 */
>-#if 0
>-			printk(KERN_INFO
>-	"XFS: mount option \"%s\" not supported for remount\n", p);
>-			return -EINVAL;
>-#else
>-			break;
>+			break 0;


break 0; doesn't make any sense in C...


-- 
"Sometimes the only way to stay sane is to go a little crazy."

  parent reply	other threads:[~2008-10-16 13:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16  0:29 [PATCH] XFS fix remount rw with unrecognized options Tim Shimmin
2008-10-16 13:41 ` Jianjun Kong
2008-10-16 13:55   ` Klaus Strebel
2008-10-16 14:07     ` Jianjun Kong
2008-10-16 13:59   ` Américo Wang [this message]
2008-10-16 22:36   ` Dave Chinner
2008-10-16 22:48     ` Timothy Shimmin
2008-10-16 17:35 ` [stable] " Greg KH
2008-10-16 18:10   ` Christoph Hellwig
2008-10-16 22:39     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081016135926.GC13374@hack.voiplan.pt \
    --to=xiyou.wangcong@gmail.com \
    --cc=jianjun@zeuux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=tes@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.