Re: [PATCH 2/4] xfs: reject completely bogus remount options

Eric Sandeen
2013-10-12T01:40:29Z

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