public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Tim Shimmin <tes@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH]
Date: Wed, 15 Oct 2008 07:43:31 -0500	[thread overview]
Message-ID: <48F5E573.2040901@sandeen.net> (raw)
In-Reply-To: <20081015070313.89A8A58FA1E9@chook.melbourne.sgi.com>

> Date: Wed, 15 Oct 2008 18:03:13 +1100
> To: options@melbourne.sgi.com, unrecognized@melbourne.sgi.com,
>         with@melbourne.sgi.com, rw@melbourne.sgi.com,
>         remount@melbourne.sgi.com, fix@melbourne.sgi.com,
>         XFS@melbourne.sgi.com


I don't think that made it to the right place ...  :)

(stable@vger.kernel.org)

-Eric

Tim Shimmin wrote:
> Hi Linus,
> 
> 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
>  		}
>  	}
> 
> 

  reply	other threads:[~2008-10-15 12:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15  7:03 [PATCH] Tim Shimmin
2008-10-15 12:43 ` Eric Sandeen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-06-24  8:13 [PATCH] Christoph Hellwig

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=48F5E573.2040901@sandeen.net \
    --to=sandeen@sandeen.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox