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

[Mark Tinguely]

On 10/11/13 20:40, Eric Sandeen wrote:
> 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 at 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

Yep, confirmed the described behavior on a RHEL 6 box without patch.
The patch looks good.

Reviewed-by: Mark Tinguely <tinguely at sgi.com>