Hide Forgot
Too late for 7.7
'slave' appears to do the trick: /etc/auto.master: /- /etc/auto.fbe -t 60 /etc/auto.fbe: /fbe/env1/proc -fstype=proc :/proc /fbe/env1/sys -rw,bind :/sys /fbe/env1/tmp -rw,bind :/tmp /fbe/env1/dev -rw,rbind :/dev /pts -fstype=devpts :/dev/pts /shm -fstype=tmpfs :/dev/shm without 'slave', when accessing /fbe/env1/dev/pts, the hang occurs as described. However this works: /etc/auto.master: /- /etc/auto.fbe -t 60,slave # ls -al /fbe/env1/dev/pts total 0 drwxr-xr-x 2 root root 0 Jun 24 14:29 . drwxr-xr-x 19 root root 3320 Jun 24 19:30 .. crw--w---- 1 root tty 136, 0 Jul 19 11:31 0 crw--w---- 1 root tty 136, 1 Jul 1 12:46 1 crw--w---- 1 root tty 136, 2 Jul 19 11:54 2 crw--w---- 1 root tty 136, 3 Jul 16 16:03 3 crw--w---- 1 root tty 136, 4 Jul 22 10:07 4 crw--w---- 1 root tty 136, 5 Jul 22 10:14 5 crw--w---- 1 root tty 136, 6 Jul 19 11:28 6 crw--w---- 1 root tty 136, 7 Jul 19 14:51 7 crw--w---- 1 root tty 136, 8 Jul 22 09:57 8 crw--w---- 1 root tty 136, 9 Jul 22 10:00 9 c--------- 1 root root 5, 2 Jun 24 14:29 ptmx (this testing on upstream, so still should be verified by the customer) I wonder if there might be a way to detect such a hang, and fail the operation (AB/BA locking is detected, for example)
(In reply to Frank Sorenson from comment #11) > 'slave' appears to do the trick: > > /etc/auto.master: > /- /etc/auto.fbe -t 60 > > /etc/auto.fbe: > /fbe/env1/proc -fstype=proc :/proc > /fbe/env1/sys -rw,bind :/sys > /fbe/env1/tmp -rw,bind :/tmp > /fbe/env1/dev -rw,rbind :/dev /pts -fstype=devpts :/dev/pts /shm > -fstype=tmpfs :/dev/shm > > without 'slave', when accessing /fbe/env1/dev/pts, the hang occurs as > described. > > However this works: > /etc/auto.master: > /- /etc/auto.fbe -t 60,slave > > # ls -al /fbe/env1/dev/pts > total 0 > drwxr-xr-x 2 root root 0 Jun 24 14:29 . > drwxr-xr-x 19 root root 3320 Jun 24 19:30 .. > crw--w---- 1 root tty 136, 0 Jul 19 11:31 0 > crw--w---- 1 root tty 136, 1 Jul 1 12:46 1 > crw--w---- 1 root tty 136, 2 Jul 19 11:54 2 > crw--w---- 1 root tty 136, 3 Jul 16 16:03 3 > crw--w---- 1 root tty 136, 4 Jul 22 10:07 4 > crw--w---- 1 root tty 136, 5 Jul 22 10:14 5 > crw--w---- 1 root tty 136, 6 Jul 19 11:28 6 > crw--w---- 1 root tty 136, 7 Jul 19 14:51 7 > crw--w---- 1 root tty 136, 8 Jul 22 09:57 8 > crw--w---- 1 root tty 136, 9 Jul 22 10:00 9 > c--------- 1 root root 5, 2 Jun 24 14:29 ptmx > > (this testing on upstream, so still should be verified by the customer) > > > I wonder if there might be a way to detect such a hang, and fail the > operation (AB/BA locking is detected, for example) The deadlock isn't a lock based problem. /nobackup/test/dev \ -rw,rbind :/dev \ /pts -fstype=devpts :/dev/pts \ /shm -fstype=tmpfs :/dev/shm This is bind mounting /dev onto /nobackup/test/dev, then mounting autofs offsets on /nobackup/test/dev/pts and /nobackup/test/dev/shm. The problem occurs because bind mounting each offset causes the autofs offset mount itself to propagate back to the root as /dev/pts and /dev/shm. Then when the mount is triggered automount tries to mount a mount target that is itself an autofs trigger causing a recursive deadlock. We could detect that and fail but the problem is then the same as the original report, certain bind mounts don't work any more! The only way to resolve it is to prevent the unwanted mount propagation from happening. I considered making the mounts propagation slave by default but the problem only occurs in a limited number of cases and I didn't want to risk causing an unexpected change in behaviour for other mounts that don't need the change. Ian
I'm closing this CANTFIX because the problem is due to changes that have been made which essentially make the kernel behave as it is supposed to and using the autofs fs mount option "slave" or "private" can be used to change the kernel behaviour to what's needed.