[PATCH] manual: Correct argument order in mount examples (bug 27207)

DJ Delorie dj@redhat.com
Fri Jan 22 18:09:29 GMT 2021


"John McCabe" <john@mccabe.org.uk> writes:
>  #include <sys/mount.h>
>  
> -mount("/dev/hdb", "/cdrom", MS_MGC_VAL | MS_RDONLY | MS_NOSUID, "");
> +mount("/dev/hdb", "/cdrom", "", MS_MGC_VAL | MS_RDONLY | MS_NOSUID, NULL);
>  
> -mount("/dev/hda2", "/mnt", MS_MGC_VAL | MS_REMOUNT, "");
> +mount("/dev/hda2", "/mnt", "", MS_MGC_VAL | MS_REMOUNT, NULL);
>  

The mount(2) man page says the last argument is:

       The data argument is interpreted by the different file systems.
       Typically it is a string of comma-separated options understood by
       this file system.  See mount(8) for details of the options
       available for each filesystem type.

and also says:

       EFAULT One of the pointer arguments points outside the user
              address space.

Based on that, I think the original "" is correct (or at least safer ;)
and that the manual was just missing the fstype argument.  I would be OK
with this patch, with that change.

But while we're here...

Also, I will point out that the options we pass are obsolete, and some
won't work in a post-2.4 world:

       The mountflags argument may have the magic number 0xC0ED
       (MS_MGC_VAL) in the top 16 bits (this was required in kernel
       versions prior to 2.4, but is no longer required and ignored if
       specified), and various mount flags in the low order 16 bits:

       MS_REMOUNT
              The following mountflags can be changed: MS_RDONLY,
              MS_SYNCHRONOUS, MS_MANDLOCK; before kernel 2.6.16, the
              following could also be changed: MS_NOATIME and
              MS_NODIRATIME; and, additionally, before kernel 2.4.10,
              the following could also be changed: MS_NOSUID, MS_NODEV,
              MS_NOEXEC.

That last paragraph is confusing; does it mean that ONLY before those
versions, or SINCE before those versions?

So we have an opportunity to update this part of our documentation, but
I won't hold back the bugfix for it.



More information about the Libc-alpha mailing list