Skip to contentSkip to conversation

tests: add test for loop option in fstab

PATCH Applied Stanislav Brabec 3 participants 15 messages Feb 11, 2016 – Mar 1, 2016 Util-Linux package

lore
Share & tools
lore

Stanislav Brabec

author
#0 lore raw

PATCH 1/1 tests: add test for loop option in fstab

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

The test is currently failing, but it should not fail once the triggering bug will be fixed.

Signed-off-by Stanislav Brabec <[email protected]>
---
 tests/expected/mount/fstab-loop |  1 +
 tests/ts/mount/fstab-loop       | 51 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)
 create mode 100644 tests/expected/mount/fstab-loop
 create mode 100755 tests/ts/mount/fstab-loop
tests/expected/mount/fstab-loop new file +1 -0
new file mode 100644
index 0000000..3582111
@@ -0,0 +1 @@
+Success
tests/ts/mount/fstab-loop new file +51 -0

51 lines not on this page · raw message

Signature · 13 lines
2.7.0

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
maintainer Applied
#1 lore raw
Quoted 5 lines · Stanislav Brabec
 tests/expected/mount/fstab-loop |  1 +
 tests/ts/mount/fstab-loop       | 51 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)
 create mode 100644 tests/expected/mount/fstab-loop
 create mode 100755 tests/ts/mount/fstab-loop

Applied, thanks. Don't fail now.

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
#2 lore raw
In reply to Stanislav Brabec
Quoted 5 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

The test is currently failing, but it should not fail once the triggering bug will be fixed.

Will this be fixed quickly? Otherwise we should add
TS_KNOWN_FAIL="yes"
to the test. Then you would still see it in the build log and test diff but it wouldn't bother you with build error.

Quoted 75 lines
Signed-off-by Stanislav Brabec <[email protected]>
---
 tests/expected/mount/fstab-loop |  1 +
 tests/ts/mount/fstab-loop       | 51
+++++++++++++++++++++++++++++++++++++++++ 2 files changed, 52
insertions(+)
 create mode 100644 tests/expected/mount/fstab-loop
 create mode 100755 tests/ts/mount/fstab-loop
(quoted diff) +0 -0

b/tests/expected/mount/fstab-loop new file mode 100644 index 0000000..3582111

tests/expected/mount/fstab-loop new file +1 -0
@@ -0,0 +1 @@
+Success
tests/ts/mount/fstab-loop new file +9 -0
new file mode 100755
index 0000000..3178b95
@@ -0,0 +1,51 @@
+#!/bin/bash
+
+#
+# Copyright (C) 2016 Stanislav Brabec <[email protected]>
+#
+# This file is part of util-linux.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published

by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version.

tests/ts/mount/fstab-loop new file +40 -1
+#
+# This file is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+TS_TOPDIR="${0%/*}/../.."
+TS_DESC="loop (fstab)"
+
+. $TS_TOPDIR/functions.sh
+ts_init "$*"
+
+ts_check_test_command "$TS_CMD_MOUNT"
+ts_check_test_command "$TS_CMD_UMOUNT"
+
+ts_skip_nonroot
+ts_check_losetup
+ts_check_prog "mkfs.ext3"
+
+IMG=$(ts_image_init)
+
+mkfs.ext3 $IMG &> /dev/null || ts_die "Cannot make ext3 on $DEVICE"
+
+[ -d "$TS_MOUNTPOINT-1" ] || mkdir -p $TS_MOUNTPOINT-1
+[ -d "$TS_MOUNTPOINT-2" ] || mkdir -p $TS_MOUNTPOINT-2
+
+ts_fstab_add "$IMG" "$TS_MOUNTPOINT-1" "ext3" "loop"
+$TS_CMD_MOUNT -a >> $TS_OUTPUT 2>&1
+
+ts_fstab_add "$IMG" "$TS_MOUNTPOINT-2" "ext3" "loop"
+$TS_CMD_MOUNT -a >> $TS_OUTPUT 2>&1
+
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT-1" >> $TS_OUTPUT 2>&1
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT-2" >> $TS_OUTPUT 2>&1
+
+ts_fstab_clean
+
+ts_log "Success"
+ts_finalize
+
--

2.7.0

author
#3 lore raw
Quoted 11 lines · Ruediger Meier
Quoted 5 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

The test is currently failing, but it should not fail once the triggering bug will be fixed.

Will this be fixed quickly? Otherwise we should add
TS_KNOWN_FAIL="yes"
to the test. Then you would still see it in the build log and test diff but it wouldn't bother you with build error.

This statement was valid in the time of sending the patch. Karel promptly fixed it, so the fix appeared in the main tree even one commit earlier:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=d58b9706ed8a10cc484835119ed10385d141eb6c

But there is a chance, that some tests were broken (or fixed) by
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=b59c3bf292269be1a203f91563b961e0062e0a5f

Fix would consist of:

If there is any _expected_ message in stderr, add it to expected/.

If there is any _unexpected_ message in stderr, it means, that the test falsely succeeded in past.

Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
#4 lore raw
In reply to Stanislav Brabec
Quoted 2 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

This test still fails if /etc/mtab is a regular file. The second mount does mount the image file again but returns with error and warning:
lt-mount: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img is already mounted
ret: 64

Could we fix that in libmount or should we skip the test in case of non-symlink /etc/mtab?

Here the full debug output of the second mount command:

xxxx: libmount: INIT: library debug mask: 0xffff
xxxx: libmount: INIT: library version: 2.26.0
xxxx: libmount: INIT: feature: btrfs
xxxx: libmount: INIT: feature: assert
xxxx: libmount: INIT: feature: debug
Available "LIBMOUNT_DEBUG=<name>[,...]|<mask>" debug masks:

   all      [0xffff] : info about all subsystems
   cache    [0xffff] : paths and tags cache
   cxt      [0xffff] : library context (handler)
   diff     [0xffff] : mountinfo changes tracking
   fs       [0xffff] : FS abstraction
   help     [0xffff] : this help
   locks    [0xffff] : mtab and utab locking
   options  [0xffff] : mount options parsing
   tab      [0xffff] : fstab, mtab, mounninfo routines
   update   [0xffff] : mtab, utab updates
   utils    [0xffff] : misc library utils
   monitor  [0xffff] : mount tables monitor
   btrfs    [0xffff] : btrfs specific routines

xxxx: libmount: CXT: [0xffff]: ----> allocate
xxxx: libmount: CXT: [0xffff]: <---- reset [status=0] ---->
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: alloc
xxxx: libmount: CACHE: [0xffff]: alloc
xxxx: libmount: TAB: [0xffff]: /etc/fstab: start parsing
[entries=0, filter=not]
xxxx: libmount: TAB: [0xffff]: add entry: LABEL=cloudimg-rootfs /
xxxx: libmount: TAB: [0xffff]: add entry: /dev/null /var/ramfs
xxxx: libmount: TAB: [0xffff]: add
entry: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: TAB: [0xffff]: add
entry: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: /etc/fstab: stop parsing (4 entries)
xxxx: libmount: TAB: [0xffff]: parsing done [filename=/etc/fstab,
rc=0]
xxxx: libmount: CXT: [0xffff]: next-mount: trying /
xxxx: libmount: CXT: [0xffff]: next-mount: not-match [fstype: ext4,
t-pattern: (null), options: defaults, O-pattern: (null)]
xxxx: libmount: CXT: [0xffff]: <---- reset [status=0] ---->
xxxx: libmount: CXT: [0xffff]: next-mount: trying /var/ramfs
xxxx: libmount: TAB: [0xffff]: alloc
xxxx: libmount: UTILS: mtab: /etc/mtab
xxxx: libmount: TAB: [0xffff]: force mtab usage
[filename=/etc/mtab]
xxxx: libmount: TAB: [0xffff]: /etc/mtab: start parsing [entries=0,
filter=not]
xxxx: libmount: TAB: trying to guess table type
xxxx: libmount: TAB: [0xffff]: add entry: /dev/sda1 /
xxxx: libmount: TAB: [0xffff]: add entry: proc /proc
xxxx: libmount: TAB: [0xffff]: add entry: sysfs /sys
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/fs/cgroup
xxxx: libmount: TAB: [0xffff]: add entry:
none /sys/fs/fuse/connections
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/kernel/debug
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/kernel/security
xxxx: libmount: TAB: [0xffff]: add entry: udev /dev
xxxx: libmount: TAB: [0xffff]: add entry: devpts /dev/pts
xxxx: libmount: TAB: [0xffff]: add entry: tmpfs /run
xxxx: libmount: TAB: [0xffff]: add entry: none /run/lock
xxxx: libmount: TAB: [0xffff]: add entry: none /run/shm
xxxx: libmount: TAB: [0xffff]: add entry: none /run/user
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/fs/pstore
xxxx: libmount: TAB: [0xffff]: add entry: /dev/null /var/ramfs
xxxx: libmount: TAB: [0xffff]: add entry:
cgroup /sys/fs/cgroup/cpuset
xxxx: libmount: TAB: [0xffff]: add entry: cgroup /sys/fs/cgroup/cpu
xxxx: libmount: TAB: [0xffff]: add entry:
binfmt_misc /proc/sys/fs/binfmt_misc
xxxx: libmount: TAB: [0xffff]: add entry:
systemd /sys/fs/cgroup/systemd
xxxx: libmount: TAB: [0xffff]: add
entry: /dev/loop0 /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: /etc/mtab: stop parsing (20 entries)
xxxx: libmount: TAB: [0xffff]: parsing done [filename=/etc/mtab,
rc=0]
xxxx: libmount: CXT: [0xffff]: mtab requested [nents=20]
xxxx: libmount: FS: [0xffff]: is FS mounted? [target=/var/ramfs,
source=/dev/null]
xxxx: libmount: FS: [0xffff]: is mounted: src=/dev/null,
tgt=/var/ramfs, root=(null)
xxxx: libmount: TAB: [0xffff]: mnt_table_is_fs_mounted: /dev/null
[rc=1]
xxxx: libmount: CXT: [0xffff]: <---- reset [status=0] ---->
xxxx: libmount: CXT: [0xffff]: next-mount:
trying /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: CXT: [0xffff]: mtab requested [nents=20]
xxxx: libmount: FS: [0xffff]: is FS mounted?
[target=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1, source=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img]
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
xxxx: libmount: CACHE: [0xffff]: add entry [ 1]
(path): /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
xxxx: libmount: FS: [0xffff]: is mounted:
src=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img, tgt=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1,
root=(null)
xxxx: libmount: TAB: [0xffff]:
mnt_table_is_fs_mounted: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
[rc=0]
xxxx: libmount: CXT: [0xffff]: mount: preparing
xxxx: libmount: CXT: [0xffff]: use default optsmode
xxxx: libmount: CXT: [0xffff]: OPTSMODE: ignore=0, append=0,
prepend=1, replace=0, force=0, fstab=1, mtab=1
xxxx: libmount: CXT: [0xffff]: fstab not required -- skip
xxxx: libmount: CXT: [0xffff]: merging mount flags
xxxx: libmount: CXT: [0xffff]: final flags: VFS=00000000
user=00000200
xxxx: libmount: CXT: [0xffff]: mount: evaluating permissions
xxxx: libmount: CXT: [0xffff]: mount: fixing optstr
xxxx: libmount: CXT: [0xffff]: mount: fixing vfs optstr
xxxx: libmount: CXT: applying 0x00000000 flags to '(null)'
xxxx: libmount: CXT: new optstr 'rw'
xxxx: libmount: CXT: [0xffff]: mount: fixing user optstr
xxxx: libmount: CXT: applying 0x00000512 flags to 'loop'
xxxx: libmount: CXT: new optstr 'loop'
xxxx: libmount: CXT: [0xffff]: fixed options [rc=0]: vfs: 'rw'
fs: '(null)' user: 'loop', optstr: 'rw,loop'
xxxx: libmount: CXT: [0xffff]: preparing source path
xxxx: libmount: CXT: [0xffff]:
srcpath '/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img'
xxxx: libmount: CXT: [0xffff]: loopdev specific options detected
xxxx: libmount: CXT: [0xffff]: trying to setup loopdev
for /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
xxxx: libmount: CXT: [0xffff]: mtab requested [nents=20]
xxxx: libmount: CXT: [0xffff]: checking
if /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
mounted
on /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: CXT:
[0xffff]: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
already mounted
xxxx: libmount: CXT: [0xffff]: mount: preparing failed
lt-mount: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
is already mounted
xxxx: libmount: CXT: [0xffff]: <---- reset [status=0] ---->
xxxx: libmount: CXT: [0xffff]: next-mount:
trying /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: CXT: [0xffff]: mtab requested [nents=20]
xxxx: libmount: FS: [0xffff]: is FS mounted?
[target=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2, source=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img]
xxxx: libmount: FS: [0xffff]: is mounted:
src=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img, tgt=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2,
root=(null)
xxxx: libmount: TAB: [0xffff]:
mnt_table_is_fs_mounted: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
[rc=0]
xxxx: libmount: CXT: [0xffff]: mount: preparing
xxxx: libmount: CXT: [0xffff]: OPTSMODE: ignore=0, append=0,
prepend=1, replace=0, force=0, fstab=1, mtab=1
xxxx: libmount: CXT: [0xffff]: fstab not required -- skip
xxxx: libmount: CXT: [0xffff]: merging mount flags
xxxx: libmount: CXT: [0xffff]: final flags: VFS=00000000
user=00000200
xxxx: libmount: CXT: [0xffff]: mount: evaluating permissions
xxxx: libmount: CXT: [0xffff]: mount: fixing optstr
xxxx: libmount: CXT: [0xffff]: mount: fixing vfs optstr
xxxx: libmount: CXT: applying 0x00000000 flags to '(null)'
xxxx: libmount: CXT: new optstr 'rw'
xxxx: libmount: CXT: [0xffff]: mount: fixing user optstr
xxxx: libmount: CXT: applying 0x00000512 flags to 'loop'
xxxx: libmount: CXT: new optstr 'loop'
xxxx: libmount: CXT: [0xffff]: fixed options [rc=0]: vfs: 'rw'
fs: '(null)' user: 'loop', optstr: 'rw,loop'
xxxx: libmount: CXT: [0xffff]: preparing source path
xxxx: libmount: CXT: [0xffff]:
srcpath '/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img'
xxxx: libmount: CXT: [0xffff]: loopdev specific options detected
xxxx: libmount: CXT: [0xffff]: trying to setup loopdev
for /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
xxxx: libmount: CXT: [0xffff]: mtab requested [nents=20]
xxxx: libmount: CXT: [0xffff]: checking
if /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop.img
mounted
on /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: CACHE: [0xffff]: add entry [ 2]
(path): /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: CACHE: [0xffff]: add entry [ 3]
(path): /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /sys/fs/cgroup/systemd
xxxx: libmount: CACHE: [0xffff]: add entry [ 4]
(path): /sys/fs/cgroup/systemd: /sys/fs/cgroup/systemd
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /proc/sys/fs/binfmt_misc
xxxx: libmount: CACHE: [0xffff]: add entry [ 5]
(path): /proc/sys/fs/binfmt_misc: /proc/sys/fs/binfmt_misc
xxxx: libmount: CACHE: [0xffff]: canonicalize path /sys/fs/cgroup/cpu
xxxx: libmount: CACHE: [0xffff]: add entry [ 6]
(path): /sys/fs/cgroup/cpu: /sys/fs/cgroup/cpu
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /sys/fs/cgroup/cpuset
xxxx: libmount: CACHE: [0xffff]: add entry [ 7]
(path): /sys/fs/cgroup/cpuset: /sys/fs/cgroup/cpuset
xxxx: libmount: CACHE: [0xffff]: canonicalize path /var/ramfs
xxxx: libmount: CACHE: [0xffff]: add entry [ 8]
(path): /var/ramfs: /var/ramfs
xxxx: libmount: CACHE: [0xffff]: canonicalize path /sys/fs/pstore
xxxx: libmount: CACHE: [0xffff]: add entry [ 9]
(path): /sys/fs/pstore: /sys/fs/pstore
xxxx: libmount: CACHE: [0xffff]: canonicalize path /run/user
xxxx: libmount: CACHE: [0xffff]: add entry [10]
(path): /run/user: /run/user
xxxx: libmount: CACHE: [0xffff]: canonicalize path /run/shm
xxxx: libmount: CACHE: [0xffff]: add entry [11]
(path): /run/shm: /run/shm
xxxx: libmount: CACHE: [0xffff]: canonicalize path /run/lock
xxxx: libmount: CACHE: [0xffff]: add entry [12]
(path): /run/lock: /run/lock
xxxx: libmount: CACHE: [0xffff]: canonicalize path /run
xxxx: libmount: CACHE: [0xffff]: add entry [13] (path): /run: /run
xxxx: libmount: CACHE: [0xffff]: canonicalize path /dev/pts
xxxx: libmount: CACHE: [0xffff]: add entry [14]
(path): /dev/pts: /dev/pts
xxxx: libmount: CACHE: [0xffff]: canonicalize path /dev
xxxx: libmount: CACHE: [0xffff]: add entry [15] (path): /dev: /dev
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /sys/kernel/security
xxxx: libmount: CACHE: [0xffff]: add entry [16]
(path): /sys/kernel/security: /sys/kernel/security
xxxx: libmount: CACHE: [0xffff]: canonicalize path /sys/kernel/debug
xxxx: libmount: CACHE: [0xffff]: add entry [17]
(path): /sys/kernel/debug: /sys/kernel/debug
xxxx: libmount: CACHE: [0xffff]: canonicalize
path /sys/fs/fuse/connections
xxxx: libmount: CACHE: [0xffff]: add entry [18]
(path): /sys/fs/fuse/connections: /sys/fs/fuse/connections
xxxx: libmount: CACHE: [0xffff]: canonicalize path /sys/fs/cgroup
xxxx: libmount: CACHE: [0xffff]: add entry [19]
(path): /sys/fs/cgroup: /sys/fs/cgroup
xxxx: libmount: CACHE: [0xffff]: canonicalize path /sys
xxxx: libmount: CACHE: [0xffff]: add entry [20] (path): /sys: /sys
xxxx: libmount: CACHE: [0xffff]: canonicalize path /proc
xxxx: libmount: CACHE: [0xffff]: add entry [21] (path): /proc: /proc
xxxx: libmount: CACHE: [0xffff]: canonicalize path /
xxxx: libmount: CACHE: [0xffff]: add entry [22] (path): /: /
xxxx: libmount: CXT: [0xffff]: enabling AUTOCLEAR flag
xxxx: libmount: CXT: [0xffff]: trying to use /dev/loop1
xxxx: libmount: CXT: [0xffff]: final srcpath '/dev/loop1'
xxxx: libmount: CXT: [0xffff]: preparing target path
xxxx: libmount: CXT: [0xffff]: final
target '/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2'
xxxx: libmount: CXT: [0xffff]: preparing fstype
xxxx: libmount: CXT: [0xffff]: FS type: ext3 [rc=0]
xxxx: libmount: CXT: [0xffff]: /sbin/mount.ext3 ... not
found
xxxx: libmount: CXT: [0xffff]: /sbin/fs.d/mount.ext3 ... not
found
xxxx: libmount: CXT: [0xffff]: /sbin/fs/mount.ext3 ... not
found
xxxx: libmount: CXT: [0xffff]: prepare update
xxxx: libmount: CXT: [0xffff]: checking for writable tab files
xxxx: libmount: UTILS: mtab: /etc/mtab
xxxx: libmount: UPDATE: [0xffff]: allocate
xxxx: libmount: UPDATE: [0xffff]: resetting FS [fs=0x0x1466eb0,
target=(null), flags=0x00000000]
xxxx: libmount: UPDATE: [0xffff]: FS template:
xxxx: libmount: UPDATE: ------ fs: 0x1466eb0
source: /dev/loop1
target: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
fstype: ext3
optstr: rw,loop
VFS-optstr: rw
user-optstr:
xxxx: libmount: UPDATE: [0xffff]: ready
xxxx: libmount: CXT: [0xffff]: mount: do mount
xxxx: libmount: CXT: [0xffff]: mount(2) [source=/dev/loop1,
target=/home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2,
type=ext3, mountflags=0xc0ed0000, mountdata=<none>]
xxxx: libmount: CXT: [0xffff]: success
xxxx: libmount: UPDATE: [0xffff]: /etc/mtab: update tab
xxxx: libmount: UPDATE: ------ fs: 0x1466220
source: /dev/loop1
target: /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
fstype: ext3
optstr: rw
VFS-optstr: rw
xxxx: libmount: LOCKS: [0xffff]: alloc: default
linkfile=/etc/mtab~.4089, lockfile=/etc/mtab~
xxxx: libmount: LOCKS: [0xffff]: signals: BLOCKED
xxxx: libmount: UPDATE: [0xffff]: /etc/mtab: add entry
xxxx: libmount: LOCKS: [0xffff]: /etc/mtab~: (4089) successfully
locked
xxxx: libmount: TAB: [0xffff]: alloc
xxxx: libmount: TAB: [0xffff]: /etc/mtab: start parsing [entries=0,
filter=not]
xxxx: libmount: TAB: [0xffff]: add entry: /dev/sda1 /
xxxx: libmount: TAB: [0xffff]: add entry: proc /proc
xxxx: libmount: TAB: [0xffff]: add entry: sysfs /sys
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/fs/cgroup
xxxx: libmount: TAB: [0xffff]: add entry:
none /sys/fs/fuse/connections
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/kernel/debug
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/kernel/security
xxxx: libmount: TAB: [0xffff]: add entry: udev /dev
xxxx: libmount: TAB: [0xffff]: add entry: devpts /dev/pts
xxxx: libmount: TAB: [0xffff]: add entry: tmpfs /run
xxxx: libmount: TAB: [0xffff]: add entry: none /run/lock
xxxx: libmount: TAB: [0xffff]: add entry: none /run/shm
xxxx: libmount: TAB: [0xffff]: add entry: none /run/user
xxxx: libmount: TAB: [0xffff]: add entry: none /sys/fs/pstore
xxxx: libmount: TAB: [0xffff]: add entry: /dev/null /var/ramfs
xxxx: libmount: TAB: [0xffff]: add entry:
cgroup /sys/fs/cgroup/cpuset
xxxx: libmount: TAB: [0xffff]: add entry: cgroup /sys/fs/cgroup/cpu
xxxx: libmount: TAB: [0xffff]: add entry:
binfmt_misc /proc/sys/fs/binfmt_misc
xxxx: libmount: TAB: [0xffff]: add entry:
systemd /sys/fs/cgroup/systemd
xxxx: libmount: TAB: [0xffff]: add
entry: /dev/loop0 /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-1
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: /etc/mtab: stop parsing (20 entries)
xxxx: libmount: TAB: [0xffff]: parsing done [filename=/etc/mtab,
rc=0]
xxxx: libmount: TAB: [0xffff]: add
entry: /dev/loop1 /home/travis/build/rudimeier/util-linux/tests/output/mount/fstab-loop-mnt-2
xxxx: libmount: UPDATE: [0xffff]: /etc/mtab: updating
xxxx: libmount: LOCKS: [0xffff]: (4089) unlocking
xxxx: libmount: LOCKS: [0xffff]: unlink /etc/mtab~
xxxx: libmount: LOCKS: [0xffff]: restoring sigmask
xxxx: libmount: TAB: [0xffff]: reset
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: free [refcount=0]
xxxx: libmount: UPDATE: [0xffff]: /etc/mtab: update tab: done [rc=0]
xxxx: libmount: LOCKS: [0xffff]: free
xxxx: libmount: CXT: [0xffff]: <---- reset [status=1] ---->
xxxx: libmount: CXT: [0xffff]: <---- reset [status=0] ---->
xxxx: libmount: TAB: [0xffff]: reset
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: reset
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: TAB: [0xffff]: free [refcount=0]
xxxx: libmount: CACHE: [0xffff]: free [refcount=0]
xxxx: libmount: CXT: [0xffff]: closing loopdev FD
xxxx: libmount: UPDATE: [0xffff]: free
xxxx: libmount: FS: [0xffff]: free [refcount=0]
xxxx: libmount: CXT: [0xffff]: <---- free

maintainer
#5 lore raw
Quoted 5 lines · Ruediger Meier
Quoted 2 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

This test still fails if /etc/mtab is a regular file.

The problem should be fixed now. Thanks!

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
author
#6 lore raw
Quoted 9 lines · On Feb 16 2016 at 15:49 Karel Zak wrote:
Quoted 5 lines · Ruediger Meier
Quoted 2 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

This test still fails if /etc/mtab is a regular file.

The problem should be fixed now. Thanks!

Well, not for btrfs. See the new testcase below (ready for inclusion to the GIT).

Only one volume is mounted, others report "already mounted".

Looking at dmesg, in difference to the previous tests, mount allocates more loop devices. And only one sub-volume is mounted after mount -a.

[25047.013991] BTRFS info (device loop0): disk space caching is enabled
[25047.013995] BTRFS: has skinny extents
[25047.405435] BTRFS info (device loop0): disk space caching is enabled
[25047.405441] BTRFS: has skinny extents
[25047.752299] BTRFS info (device loop1): disk space caching is enabled
[25047.752302] BTRFS: has skinny extents
        mount: btrfs (fstab)                  ...
                : btrfs                       ... OK
                : auto                        ... OK
                : loop                        ... FAILED (mount/fstab-btrfs-loop)

... FAILED (1 from 3 sub-tests)
mount: loop (fstab) ... OK

mount: /dev/loop2 is already mounted or /home/sbrabec/VCS-my/util-linux-btrfs-fixes-loop/tests/output/mount/fstab-btrfs-mnt-default busy
umount: /home/sbrabec/VCS-my/util-linux-btrfs-fixes-loop/tests/output/mount/fstab-btrfs-mnt-bind: not mounted
umount: /home/sbrabec/VCS-my/util-linux-btrfs-fixes-loop/tests/output/mount/fstab-btrfs-mnt-subvol: not mounted
umount: /home/sbrabec/VCS-my/util-linux-btrfs-fixes-loop/tests/output/mount/fstab-btrfs-mnt-subvolid: not mounted

Here is a new testcase:

Quoted 1 line

From 559933a158d822852f1d06db02320646f237c4b8 Mon Sep 17 00:00:00 2001

From: Stanislav Brabec <[email protected]>
Date: Fri, 19 Feb 2016 19:02:53 +0100
Subject: [PATCH] tests: add btrfs loop mount tests

btrfs needs a special support in loop mount. Add a testcase for btrfs specific problems.

It is a cut-and-paste of previous sub-test, just the fstab syntax is different.

Signed-off-by Stanislav Brabec <[email protected]>
---
 tests/expected/mount/fstab-btrfs-loop |  1 +
 tests/ts/mount/fstab-btrfs            | 28 +++++++++++++++++++++++++++-
 2 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 tests/expected/mount/fstab-btrfs-loop
tests/expected/mount/fstab-btrfs-loop new file +1 -0
new file mode 100644
index 0000000..3582111
@@ -0,0 +1 @@
+Success
tests/ts/mount/fstab-btrfs +27 -1
index d14ad10..f3af9f9 100755
@@ -36,7 +36,7 @@ TS_MOUNTPOINT_SUBVOL="$TS_MOUNTPOINT-subvol"
 TS_MOUNTPOINT_SUBVOLID="$TS_MOUNTPOINT-subvolid"
 TS_MOUNTPOINT_BIND="$TS_MOUNTPOINT-bind"
 
-ts_device_init 42
+ts_device_init 42 "$TS_OUTDIR/${TS_TESTNAME}.img"
 DEVICE=$TS_LODEV
 [ -d "$TS_MOUNTPOINT_CREATE" ] || mkdir -p "$TS_MOUNTPOINT_CREATE"
 [ -d "$TS_MOUNTPOINT_DEFAULT" ] || mkdir -p "$TS_MOUNTPOINT_DEFAULT"

@@ -123,6 +123,32 @@ ts_fstab_clean
 ts_log "Success"
 ts_finalize_subtest
 
+ts_init_subtest "loop"
+# Tests with "loop" in options syntax
+# mounting default subvolume, deep in the structure, without entry in fstab
+ts_fstab_add "$TS_OUTDIR/${TS_TESTNAME}.img" "$TS_MOUNTPOINT_DEFAULT" "btrfs" "loop"
+# mounting default subvolume, deep in the structure
+ts_fstab_add "$TS_OUTDIR/${TS_TESTNAME}.img" "$TS_MOUNTPOINT_SUBVOL" "btrfs" "loop,subvol=$NON_DEFAULT_SUBVOL"
+# mounting non-default subvolume
+ts_fstab_add "$TS_OUTDIR/${TS_TESTNAME}.img" "$TS_MOUNTPOINT_SUBVOLID" "btrfs" "subvolid=$NON_DEFAULT_SUBVOLID,loop"
+# test bind mount pointing to subvolume sub-directory
+ts_fstab_add "$TS_MOUNTPOINT_SUBVOL/bind-mnt" "$TS_MOUNTPOINT_BIND" "auto" "bind"
+
+$TS_CMD_MOUNT -a >> $TS_OUTPUT 2>&1
+$TS_CMD_MOUNT -a >> $TS_OUTPUT 2>&1
+
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT_BIND" >> $TS_OUTPUT 2>&1
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT_DEFAULT" >> $TS_OUTPUT 2>&1
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT_SUBVOL" >> $TS_OUTPUT 2>&1
+$TS_CMD_UMOUNT "$TS_MOUNTPOINT_SUBVOLID" >> $TS_OUTPUT 2>&1
+
+# check that everything was unmounted
+$TS_CMD_MOUNT | grep "$TS_MOUNTPOINT_ANY" >> $TS_OUTPUT 2>&1
+
+ts_fstab_clean
+ts_log "Success"
+ts_finalize_subtest
+
 
 ts_finalize
Signature · 13 lines
2.7.1

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
maintainer
#7 lore raw
Quoted 6 lines · Stanislav Brabec
Quoted 5 lines · On Feb 16 2016 at 15:49 Karel Zak wrote:
Quoted 4 lines · Ruediger Meier
Quoted 2 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

This test still fails if /etc/mtab is a regular file.

The problem should be fixed now. Thanks!

Well, not for btrfs. See the new testcase below (ready for inclusion to the GIT).

Do you mean when /etc/mtab is a regular file? For btrfs we need fs root and this information is nowhere in mtab (and maybe another information related to subvolumes which we have in mountinfo).

Not sure if we really need to support this complicated use-case with deprecated mtab.

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
#8 lore raw
Quoted 6 lines · Karel Zak

Do you mean when /etc/mtab is a regular file? For btrfs we need fs root and this information is nowhere in mtab (and maybe another information related to subvolumes which we have in mountinfo).

Not sure if we really need to support this complicated use-case with deprecated mtab.

I wonder what could be the reason why some admins manually setup mtab files eventhough their distro's default is to use a link to /proc.

For example on OBS (openSUSE build farm) they have always mtab files for any build host. Also travis is using files for Ubuntu 12.04 and 14.04.

Is there any good reason for this? Maybe it's better for docker containers or if you run things in a chroot?

cu,
Rudi

maintainer
#9 lore raw
Quoted 8 lines · Ruediger Meier
Quoted 6 lines · Karel Zak

Do you mean when /etc/mtab is a regular file? For btrfs we need fs root and this information is nowhere in mtab (and maybe another information related to subvolumes which we have in mountinfo).

Not sure if we really need to support this complicated use-case with deprecated mtab.

Quoted 7 lines

I wonder what could be the reason why some admins manually setup mtab files eventhough their distro's default is to use a link to /proc.

For example on OBS (openSUSE build farm) they have always mtab files for any build host. Also travis is using files for Ubuntu 12.04 and 14.04.

Is there any good reason for this? Maybe it's better for docker

No reason, in the hell is special hot room where is "mtab users" written by blood on the dark heavy doors...

Quoted 1 line

containers or if you run things in a chroot?

I can't imagine usable chroot/container without /proc. The docker don't use systemd so maybe they have not been forced to leave mtab.

Karel

Signature · 2 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
author
#10 lore raw
In reply to Karel Zak
Quoted 9 lines · On Feb 22, 2016 at 11:12 Karel Zak wrote:
Quoted 8 lines · Stanislav Brabec
Quoted 7 lines · On Feb 16 2016 at 15:49 Karel Zak wrote:
Quoted 5 lines · Ruediger Meier
Quoted 2 lines · Stanislav Brabec

Add a new fstab tests which check loop mount of the same source multiple times in multiple steps.

This test still fails if /etc/mtab is a regular file.

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

The problem should be fixed now. Thanks!

Well, not for btrfs. See the new testcase below (ready for inclusion to the GIT).

Do you mean when /etc/mtab is a regular file? For btrfs we need fs root and this information is nowhere in mtab (and maybe another information related to subvolumes which we have in mountinfo).

No, My new testcase fails on a system with mtab being a symlink:

# ls -al /etc/mtab
lrwxrwxrwx 1 root root 19 Jul  7  2015 /etc/mtab -> ../proc/self/mounts

Not tested with a file.

Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
author
#11 lore raw
Quoted 7 lines · On Feb 22, 2016 at 17:36 Stanislav Brabec wrote:

No, My new testcase fails on a system with mtab being a symlink:

# ls -al /etc/mtab
lrwxrwxrwx 1 root root 19 Jul  7  2015 /etc/mtab -> ../proc/self/mounts

Not tested with a file.

I just analyzed the loop test case failure in deep. It has nothing to do with mtab, but with a fact, that manual losetup with subsequent mount commands recycle the same loop device, but -oloop allocates new loop device for each mount where loop option is used.

And it is something that kernel does not like.

Here is a simplified example:

# losetup /dev/loop0 tests/output/mount/fstab-btrfs.img
# losetup /dev/loop1 tests/output/mount/fstab-btrfs.img
# mount /dev/loop0 /mnt/0
# mount -osubvol=/ /dev/loop1 /mnt/1
mount: /dev/loop1 is already mounted or /mnt/1 busy
       /dev/loop1 is already mounted on /mnt/1

Note: default of fstab-btrfs.img is not /, each mount should mount a different sub-volume.

David, is it an expected kernel behavior?

If not, it is a kernel bug.

If yes, util-linux needs additional logic:

If "loop" options is used, check, whether the source equals to a source of another loop mount. If it is, don't allocate new loop device, but recycle existing one.

And reciprocally, if umount on such device is used, don't free the loop device as long as there is another volume mounted that shares this source.

Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
author
#12 lore raw

Re: [PATCH] tests: add test for loop option in fstab (my mistake, and two new bugs, one in kernel)

Quoted 3 lines · On Feb 24, 2016 at 19:58 Stanislav Brabec wrote:
# mount -osubvol=/ /dev/loop1 /mnt/1
mount: /dev/loop1 is already mounted or /mnt/1 busy
        /dev/loop1 is already mounted on /mnt/1

OOPS, sorry, my mistake. I forgot loop mounted on /mnt/1 that confused me.

But I already found a real explanation of the umount error in the test case failure: There is a kernel bug!

# mount -oloop tests/output/mount/fstab-btrfs.img /mnt
# mount -oloop,subvol=/ tests/output/mount/fstab-btrfs.img /mnt2

Both succeeded and returned code 0.

Two mounts should be created, but only one is:

# mount | grep mnt
/dev/loop1 on /mnt type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/d0/dd0/ddd0/s1/d1/dd1/ddd1/s2)

Yes, /mnt2 was ignored.

Once I
umount /mnt
it succeeds:

# mount | grep mnt
/home/sbrabec/util-linux/tests/output/mount/fstab-btrfs.img on /mnt2 type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)

Surprisingly, the format of the mount line is different.

And even more surprisingly, strace shows:

mount("/dev/loop1", "/mnt2", "btrfs", MS_MGC_VAL, "subvol=/") = 0
access("/mnt2", W_OK) = 0

=> It looks like a kernel bug.
Kernel is openSUSE Tumbleweed linux-4.4.1-1.

Looking deeper, the different format of lines seems to be util-linux fault, because /proc/self/mountinfo lines are in an equal format:

222 59 0:71 /d0/dd0/ddd0/s1/d1/dd1/ddd1/s2 /mnt rw,relatime shared:150 - btrfs /dev/loop0 rw,space_cache,subvolid=257,subvol=/d0/dd0/ddd0/s1/d1/dd1/ddd1/s2

222 59 0:71 / /mnt2 rw,relatime shared:150 - btrfs /dev/loop0 rw,space_cache,subvolid=5,subvol=/

=> This one looks like an util-linux bug.

It seems, that also the code evaluating loop mounts needs btrfs default subvolume check. Because it starts to work, if I specify subvol or subvolid of the default mount explicitly.

# mount -oloop,subvol=/d0/dd0/ddd0/s1/d1/dd1/ddd1/s2 tests/output/mount/fstab-btrfs.img /mnt
/home/sbrabec/util-linux/tests/output/mount/fstab-btrfs.img on /mnt type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/d0/dd0/ddd0/s1/d1/dd1/ddd1/s2)
# mount -oloop,subvolid=257 tests/output/mount/fstab-btrfs.img /mnt
# mount | grep mnt
/home/sbrabec/util-linux/tests/output/mount/fstab-btrfs.img on /mnt type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/d0/dd0/ddd0/s1/d1/dd1/ddd1/s2)
Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
author
#13 lore raw

Re: [PATCH] tests: add test for loop option in fstab (my mistake, and two new bugs, one in kernel)

Quoted 2 lines · On Feb 24, 2016 at 22:33 Stanislav Brabec wrote:

=> It looks like a kernel bug.
Kernel is openSUSE Tumbleweed linux-4.4.1-1.

Analyzed and sent to LKML.
http://marc.info/?l=linux-kernel&m=145642818824430&w=2

It seems that problem reported here is triggered by multiple mounts using multiple loop devices pointing to the same file.

Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
author
#14 lore raw

Re: [PATCH] tests: add test for loop option in fstab (my mistake, and two new bugs, one in kernel)

Quoted 11 lines · On Feb 25, 2016 at 20:31 Stanislav Brabec wrote:
Quoted 2 lines · On Feb 24, 2016 at 22:33 Stanislav Brabec wrote:

=> It looks like a kernel bug.
Kernel is openSUSE Tumbleweed linux-4.4.1-1.

Analyzed and sent to LKML.
http://marc.info/?l=linux-kernel&m=145642818824430&w=2

It seems that problem reported here is triggered by multiple mounts using multiple loop devices pointing to the same file.

And not only that it breaks structures.

Even if structures will be kept in order, it will cause data
corruption: kernel does not have an information, that both loop devices point to the same device:

Here is an analysis of Al Viro[1]:

Sigh... sys_mount() (mount_bdev(), actually) has no way to tell if two loop devices refer to the same underlying object. As far as it's concerned, you are asking to mount a completely unrelated block device. Which just happens to see the data (living in separate pagecache, even) modified behind its back (with some delay) after it gets written to another device. Filesystem drivers generally don't like when something is screwing the underlying data, to put it mildly...

When you ask to mount the _same_ device, mount_bdev(), as well as btrfs counterpart, makes sure that you get a reference to the same struct super_block, which avoids all coherency problems - all mounted instances refer to the same in-core objects (dentries, inodes, page cache, etc.). They get separate struct vfsmount instances, but that only matters for mountpoint crossing.

As soon as you've set the second /dev/loop alias for the same underlying file, you are asking for all kinds of trouble. If you use the same one consistently, you are OK. BTW, even
losetup /dev/loop0 /dev/sda1
mount -t ext2 /dev/sda1 /mnt/1
mount -t ext2 /dev/loop0 /mnt/2
is enough for trouble - you get (as far as ext2 knows) unrelated devices screwing each other, with no good way to predict that. And you need to check propagation through more than one layer - loop over loop over block is also possible.

IMO on-demand losetup a-la -o loop is simply a bad idea...

References:
[1] https://lkml.org/lkml/2016/2/26/897

Signature · 10 lines
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: [email protected]
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                 fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76