All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 2/4] xfs: reject completely bogus remount options
Date: Fri, 11 Oct 2013 16:34:16 -0500	[thread overview]
Message-ID: <52586ED8.3030804@sgi.com> (raw)
In-Reply-To: <52584D56.7090902@sandeen.net>

On 10/11/13 14:11, Eric Sandeen wrote:
> There's a long comment about handling non-remountable
> options in xfs_fs_remount, but nothing addresses the case
> of completely bogus mount options at remount time, which
> can lead to some severe strangeness:
>
> # for I in `seq 1 10`; do mount -o remount,noacl /mnt/test2; done
> # for I in `seq 1 10`; do mount -o remount,badoption /mnt/test2; done
> # grep sdb4 /etc/mtab
> /dev/sdb4 /mnt/test2 xfs rw,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption 0 0
>
> This is a bit of a hack, but we can re-use xfs_parseargs()
> with a dummy mount struct to just vet all of the remount
> options which were passed in.  With this, we get a saner
> result:
>
> [44898.102990] EXT4-fs (sdb4): Unrecognized mount option "badoption" or missing value
>
> if we try to remount with something ridiculous.
>
> In the long run we should probably revamp a lot of the mount option
> handling...
>
> Signed-off-by: Eric Sandeen<sandeen@redhat.com>
> ---


I don't seem to get the duplicate mtab entries on a top of tree kernel.
Is this still appropriate?

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-10-11 21:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 19:07 [PATCH 0/4] xfs: old lost patches Eric Sandeen
2013-10-11 19:09 ` [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings Eric Sandeen
2013-10-11 21:59   ` Mark Tinguely
2013-10-12  1:45     ` Eric Sandeen
2013-10-12  1:59   ` [PATCH 1/4 V2] xfs: remove newlines from strings passed to __xfs_printk Eric Sandeen
2013-10-12 21:07     ` Mark Tinguely
2013-10-11 19:11 ` [PATCH 2/4] xfs: reject completely bogus remount options Eric Sandeen
2013-10-11 21:34   ` Mark Tinguely [this message]
2013-10-12  1:40     ` Eric Sandeen
2013-10-12 21:11       ` Mark Tinguely
2013-10-13 21:52   ` Dave Chinner
2013-10-14  2:42     ` Eric Sandeen
2013-10-14  4:45       ` Dave Chinner
2013-10-15 18:13         ` Eric Sandeen
2013-10-11 19:12 ` [PATCH 3/4] xfs: don't emit corruption noise on fs probes Eric Sandeen
2013-10-11 21:21   ` Mark Tinguely
2013-10-15 19:42   ` Christoph Hellwig
2013-10-11 19:14 ` [PATCH 4/4] xfs: don't break from growfs ag update loop on error Eric Sandeen
2013-10-17 18:51 ` [PATCH 0/4] xfs: old lost patches Ben Myers

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=52586ED8.3030804@sgi.com \
    --to=tinguely@sgi.com \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    --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.