Re: 2.4.0test1-ac4 - mount problem

From: Andries Brouwer (aeb@veritas.com)
Date: Wed May 31 2000 - 04:10:33 EST


Alexander Viro writes:

> Alan, if we are talking about that sort of races we are in for a lot of
> fun with mount(8) and /etc/mtab. Not that it was that critical (personally
> I'ld rather see /etc/mtab dead)

/etc/mtab gives some vague idea of what might be mounted at present.
Since there are no guarantees at all (everyone can use the system
call mount() without going through mount(8), or one can use "mount -n",
or /etc was on a read-only filesystem, or the disk was full, or ..)
it does not matter in the least that there are race conditions.
However, if everyone goes through mount(8) then locking is done.

> Yes, MNT_NOT_IF_ROOT makes sense. However, I'ld rather postpone that one
> until the decision on mount(2) interface (or the interface of whatever new
> syscall(s) will be used). I mean, just look at mount(8) syntax:

Wait! The mount(8) syntax is completely irrelevant for the mount(2) API.

> If we need to change mount(8) (and looks like we do)

Maybe there is no need for drastic changes. More like a three-line patch.
And maybe not even that.

The problem is clear: the present situation gives us the same filesystem
mounted many times at the same place, and we don't want that.

So, the condition is: look at the filesystem and the mountpoint.
If the same filesystem is already the top one mounted at this mountpoint
and this is not a remount, return EBUSY.

No syntax changes, no API changes.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:27 EST