> Good point. After coming up with a patch which solves this, I then
> discovered that umount(8) already follows symlinks in userland
> before it calls umount(2) (actually oldumount(2)). That means that
> mount(8) works fine with my original patch even for symlinks like
> /dev/cdrom. It also works OK with mine because if I do
> mount -t mls ... /tmp/mls
> then readlink on /tmp/mls produces "[MLS]" while follow_link does
> the magic of redirection. umount(8) tried to find /tmp/[MLS], fails
> with ENOENT and then goes and ahead and calls oldumount(2) on
> "/tmp/mls", trusting that the caller knows what they're doing.
>
> If having the system call itself follow symlinks where appropriate
> is considered absolutely necessary (rather than leaving it up to
> userland) then the following patch solves it, but it looks to me as
> though the kernel is cleaner if it just assumes the caller passes in
> the right name to start with.
Go for simpler patch assuming umount does the work...
-- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org- 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/