On Mon, Aug 19, 2019 at 04:30:22PM +0800, Kevin Hao wrote:
> The "umount -f -a -r" get stuck in a endless loop when run with a
> mountinfo like below:
> 15 0 179:2 / / ro,relatime - ext4 /dev/root ro
> 16 15 0:6 / /dev rw,relatime - devtmpfs devtmpfs rw,size=242896k,nr_inodes=60724,mode=755
> 17 15 0:4 / /proc rw,relatime - proc proc rw
> 18 15 0:15 / /mnt/.psplash rw,relatime - tmpfs tmpfs rw,size=40k
> 19 15 0:16 / /sys rw,relatime - sysfs sysfs rw
> 20 19 0:7 / /sys/kernel/debug rw,relatime - debugfs debugfs rw
> 21 15 0:17 / /run rw,nosuid,nodev - tmpfs tmpfs rw,mode=755
> 22 15 0:18 / /var/volatile rw,relatime - tmpfs tmpfs rw
> 23 15 179:1 / /boot rw,relatime - vfat /dev/mmcblk0p1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
> 24 16 0:19 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
> 25 18 0:20 / /mnt/.psplash rw,relatime - tmpfs tmpfs rw,size=40k
>
> The reason is that the two same mnt entry "/mnt/.psplash" will cause
> the dst->tab set to NULL when umount this mnt entry the second time.
> This will trigger an endless loop in mnt_reset_table() because that
> mnt entry is linked on the libmnt_table but its .tab is set to NULL.
Good catch! Applied.
The cxt->fs usually does not point to any table, but it's context
specific setting. Unfortunately, umount --all is different, rather
than copy always a new setting from mount table (mtab) it point to the
file. This optimization works thanks to reference counting, but now we
also check for fs->tab and it makes things more tricky.
Thanks!
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
