]> git.ipfire.org Git - thirdparty/systemd.git/commit - src/core/mount.c
core: Do not bind a mount unit to a device, if it was from mountinfo 2017/head
authorHarald Hoyer <harald@redhat.com>
Tue, 24 Nov 2015 08:41:26 +0000 (09:41 +0100)
committerHarald Hoyer <harald@redhat.com>
Tue, 24 Nov 2015 13:08:50 +0000 (14:08 +0100)
commit9d06297e262966de71095debd1537fc223f940a3
tree9f70586f2c2a8b849df7e80441bdc63483442654
parente35a7876b4ab1d53a7539a905613e31dc6ae50fd
core: Do not bind a mount unit to a device, if it was from mountinfo

If a mount unit is bound to a device, systemd tries to umount the
mount point, if it thinks the device has gone away.

Due to the uevent queue and inotify of /proc/self/mountinfo being two
different sources, systemd can never get the ordering reliably correct.

It can happen, that in the uevent queue ADD,REMOVE,ADD is queued
and an inotify of mountinfo (or libmount event) happend with the
device in question.

systemd cannot know, at which point of time the mount happend in the
ADD,REMOVE,ADD sequence.

The real ordering might have been ADD,REMOVE,ADD,mount
and systemd might think ADD,mount,REMOVE,ADD and would umount the
mountpoint.

A test script which triggered this behaviour is:
rm -f test-efi-disk.img
dd if=/dev/null of=test-efi-disk.img bs=1M seek=512 count=1
parted --script test-efi-disk.img \
  "mklabel gpt" \
  "mkpart ESP fat32 1MiB 511MiB" \
  "set 1 boot on"
LOOP=$(losetup --show -f -P test-efi-disk.img)
udevadm settle
mkfs.vfat -F32 ${LOOP}p1
mkdir -p mnt
mount ${LOOP}p1 mnt
... <dostuffwith mnt>

Without the "udevadm settle" systemd unmounted mnt while the script was
operating on mnt.

Of course the question is, why there was a REMOVE in the first place,
but this is not part of this patch.
src/core/mount.c
src/core/socket.c
src/core/swap.c
src/core/unit.c
src/core/unit.h