xfs
[Top] [All Lists]

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

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH 2/4] xfs: reject completely bogus remount options
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Fri, 11 Oct 2013 16:34:16 -0500
Cc: Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52584D56.7090902@xxxxxxxxxxx>
References: <52584C8A.1060808@xxxxxxxxxx> <52584D56.7090902@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
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@xxxxxxxxxx>
---


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

--Mark.

<Prev in Thread] Current Thread [Next in Thread>