Cfrtjryk

Working on systemd-shutdown, it is using mount() to remount filesystems as read-only.

/* MS_REMOUNT requires that the data parameter

 * should be the same from the original mount

 * except for the desired changes. Since we want

 * to remount read-only, we should filter out

 * rw (and ro too, because it confuses the kernel) */

...filter_options(m->options, "rwro", NULL, NULL, &options);



...mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, options)...

But when I looked at strace mount -oremount,rw /boot, the mount system call was passed NULL as its last argument. Does that show it's not actually necessary to copy and mangle the old option string?

No.

If you edit /etc/fstab and add a non-generic option foo, then /sbin/mount will pass "foo" as the last argument to mount(). In your example, it was passing NULL, but I think it meant the empty string "". Presumably they have the same effect.

Apparently /sbin/mount behaves differently if you pass both a path and device (!).

The remount functionality follows the standard way the mount command works with options from fstab. This means that mount does not
read fstab (or mtab) only when both device and dir are specified.

 mount -o remount,rw /dev/foo /dir

After this call all old mount options are replaced and arbitrary stuff from fstab (or mtab) is ignored, except the loop= option
which is internally generated and maintained by the mount command.

 mount -o remount,rw  /dir

After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found
in fstab, then a remount with unspecified source is allowed.

By implication, it seems that last case also overrides any current options of the mount point.

The code quoted in the question is somewhat suspicious. It appears to reset the mount flags. Current behaviour:

Remounting an existing mount

... The mountflags and data arguments should match the values used in the original mount() call, except for those parameters that are being deliberately changed.

so that's probably where the comment came from.

The following mountflags can be changed: MS_LAZYTIME, MS_MANDLOCK, MS_NOATIME, MS_NODEV, MS_NODIRATIME, MS_NOEXEC, MS_NOSUID, MS_RELATIME,
MS_RDONLY, and MS_SYNCHRONOUS.

I guess the code is currently working ok. Remounting as read-only avoids questions about subsequent writes, or a read-write remount being denied because the blockdev is readonly. And systemd-shutdown should have sent SIGKILL to any other processes with access to the filesystem by this point, so we can probably ignore security options like NOEXEC.

Attempts to change the setting of the MS_DIRSYNC flag during a remount are silently ignored.

Although it implies other flags might not be silently ignored and could cause the call to fail if they don't match, I don't think the core kernel code does anything like that.

Since Linux 3.17, if none of MS_NOATIME, MS_NODIRATIME, MS_RELATIME, or MS_STRICTATIME is specified in mountflags, then the remount operation preserves the existing values of these flags (rather than defaulting to MS_RELATIME).

Since Linux 2.6.26, this flag can also be used to make an existing bind mount read-only by specifying mountflags as:

MS_REMOUNT | MS_BIND | MS_RDONLY

I guess it's just as well systemd-shutdown didn't process fstab the exact same way mount -oremount,ro /boot would have :). (The old sysvinit scripts are ok at least in Debian, because they don't use remount RO for anything other than the root filesystem).