`Luciano Andress Martini` points out:

> First time I have a problem in a filesystem in linux I received a message by `fsck` like "/dev/hda2 is mounted read-write".  In that epoch (1999), I did not understand what that means.  I am 11 y.o. The only thing that come to my mind was: `umount /`, and it works (as it remounted read-only). 

(This requires there are no files open for writing, e.g. because the system is running in single-user mode.)

So if you don't know how to remount a filesystem as read-only, you can desperately try the same commands as if you needed to fsck (repair) `/dev/fd0` or your `/home` filesystem.  The special case means this can work, even though the `fsck` command is on the filesystem you apparently unmounted :-).  It's nice that Linux can be helpful like this, when you try to recover a corrupted system.

There is one other use of this special case: `umount -a` in old shutdown scripts.  This is defined to simply unmount all filesystems in reverse order, finishing with the root filesystem.  This makes sure all filesystems are in a consistent state on the disk, so they do not require a `fsck` on the next boot.  The Linux kernel does *not* shut down any filesystem automatically; you need to have some shutdown program or "init system" that does this.

I'm not certain why this special case is in the kernel, rather than in the `umount` command.  One reason might be that old kernels accepted the name of the mounted device, instead of the directory the filesystem was mounted at.  So perhaps putting the check in the kernel was considered simpler or more reliable.

The special case is not documented in the current man pages for `umount(2)` or `umount(8)`.  So the current man page implies that `umount -a` will always fail, but this is not the case.  I suspect that `umount -a` is not very widely used nowadays.

A very similar code comment is present in early versions of Linux [including 0.99.10 (1993)](https://github.com/mpe/linux-fullhistory/blame/238327caacec57ec3c9e6a1db02370f3deec0c93/fs/super.c#L361).  But it does not seem to be a standard for traditional UNIX.  The FreeBSD kernel [returns an error instead](https://github.com/freebsd/freebsd/blob/release/11.2.0/sys/kern/vfs_mount.c#L1255), and the FreeBSD equivalent of `umount -a` stops before unmounting the first filesystem i.e. the root.  (The code is [here](https://github.com/freebsd/freebsd/blob/master/sbin/umount/umount.c#L162), but you need to understand how `for` loops and array indexes work in C :-).

The old scripts using `umount -a` contrast with current scripts for SysVinit, for example in Debian.  `/etc/init.d/umount_root` explicitly remounts `/` as readonly.  The rest of the mounts are processed individually, by `/etc/init.d/umountfs` and `/etc/init.d/umountnfs.sh`.

`umount -a` is not ideal on modern systems.  E.g. it is simpler to leave a `/proc` filesystem mounted so that `/proc/mounts` can still be used.  And `/dev` is usually a separate mounted filesystem, which will show an unmount error because `/dev/console` is still open.

For an example of an old shutdown script, see the reference script `etc/rc.d/rc.0` in the old `SysVinit-2.4.tar.z` / `SysVinit-2.4.tar.gz`.

    #! /bin/sh
    #
    # brc		This file is executed by init(8) when the system is being
    #		shutdown (i.e. set to run at level 0).  It usually takes
    #		care of un-mounting al unneeded file systems.
    #
    # Version:	@(#)/etc/brc		2.01	02/17/93
    #
    # Authors:	Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
    #		Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
    #
    
      PATH=/bin:/etc:/usr/bin
      echo Unmounting file systems.....
      umount -a
      echo Done.