From: Eric Sandeen <sandeen@sandeen.net>
To: Mark Tinguely <tinguely@sgi.com>
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 20:40:20 -0500 [thread overview]
Message-ID: <5258A884.7000104@sandeen.net> (raw)
In-Reply-To: <52586ED8.3030804@sgi.com>
On 10/11/13 4:34 PM, Mark Tinguely wrote:
> 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?
Maybe different mount(8) behavior on your system? (probably symlinked to /proc/mounts)
On RHEL6:
# mount /dev/sdb1 /mnt/test
# for I in `seq 1 10`; do mount -o remount,noacl /mnt/test; done
# mount | grep sdb1
/dev/sdb1 on /mnt/test type xfs (rw,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl)
# uname -a
Linux hostname 3.12.0-rc4+ #41 SMP Fri Oct 11 19:43:01 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux
-Eric
> --Mark.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-10-12 1:40 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
2013-10-12 1:40 ` Eric Sandeen [this message]
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=5258A884.7000104@sandeen.net \
--to=sandeen@sandeen.net \
--cc=sandeen@redhat.com \
--cc=tinguely@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.