Bug 154385 - Crash on relocated automounts with --bind
Crash on relocated automounts with --bind
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brian Brock
Depends On:
Blocks: 168424
  Show dependency treegraph
Reported: 2005-04-11 05:58 EDT by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 10:55:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2005-04-11 05:58:44 EDT
Make /redhat an auto mounted path for autofs:

$ grep auto /proc/mounts
automount(pid1844) /redhat autofs rw 0 0
$ mkdir ~/bind
$ mount --bind /redhat bind
$ cd bind/rpms
$ ~/bind/rpms >ls

Here's the backtrace:
Mar 21 13:41:25 xldn0688nap  Unable to handle kernel NULL pointer dereference at
virtual address 00000040
Mar 21 13:41:25 xldn0688nap   printing eip:
Mar 21 13:41:25 xldn0688nap  c011fd1d
Mar 21 13:41:25 xldn0688nap  *pde = 2c2e1001
Mar 21 13:41:25 xldn0688nap  *pte = 00000000
Mar 21 13:41:25 xldn0688nap  Oops: 0000
Mar 21 13:41:25 xldn0688nap  netconsole nfs lockd sunrpc autofs4 audit tg3 sg
scsi_mod microcode loop keybdev mousedev hid input usb-ohci usbcore ext3 jbd
Mar 21 13:41:25 xldn0688nap  CPU:    1
Mar 21 13:41:25 xldn0688nap  EIP:    0060:[<c011fd1d>]    Not tainted
Mar 21 13:41:25 xldn0688nap  EFLAGS: 00010086
Mar 21 13:41:25 xldn0688nap   
Mar 21 13:41:25 xldn0688nap  EIP is at do_page_fault [kernel] 0x2d
Mar 21 13:41:25 xldn0688nap  eax: 00000000   ebx: c4ee0000   ecx: 00000040  
edx: c4ee00f0
Mar 21 13:41:25 xldn0688nap  esi: c4ee0000   edi: c011fcf0   ebp: c4ed6940  
esp: c4ee0024
Mar 21 13:41:25 xldn0688nap  ds: 0068   es: 0068   ss: 0068
Mar 21 13:41:25 xldn0688nap  Process swapper (pid: 0, stackpage=c4edf000)
Mar 21 13:41:25 xldn0688nap  Stack: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000040  
Mar 21 13:41:25 xldn0688nap         00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000  
Mar 21 13:41:25 xldn0688nap         00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000  
Mar 21 13:41:25 xldn0688nap  Call Trace:   [<c011fcf0>] do_page_fault [kernel]
0x0 (0xc4ee00dc)
Mar 21 13:41:25 xldn0688nap  [<c011fcf0>] do_page_fault [kernel] 0x0 (0xc4ee0100)
Mar 21 13:41:25 xldn0688nap  [<c011fd1d>] do_page_fault [kernel] 0x2d (0xc4ee0118)
Mar 21 13:41:25 xldn0688nap  [<c011fcf0>] do_page_fault [kernel] 0x0 (0xc4ee01dc)
Mar 21 13:41:25 xldn0688nap  [<c011fcf0>] do_page_fault [kernel] 0x0 (0xc4ee0200)
Mar 21 13:41:25 xldn0688nap  [<c011fd1d>] do_page_fault [kernel] 0x2d (0xc4ee0218)
Comment 3 Jeffrey Moyer 2005-05-17 16:32:16 EDT
The first question we should be asking here is why would you do this?  This
doesn't really seem like a high priority bug to me, unless the reporter can
justify why doing this is necessary and explain why symlinks aren't a valid
Comment 5 Jeffrey Moyer 2005-05-17 18:26:40 EDT
First, mount --bind only copies from a single file system, it does not follow
submounts.  I'm guessing what you wanted was --rbind, which would include all
other vfsmounts attached from that point in the file system hierarchy.

However, this makes a copy of all of the associated vfsmount structures at the
time of the mount.  Any further modifications in the source directory are not
reflected in the destination directory.

Now, adding automounter into this mix just isn't going to happen without
changing the kernel protocol.  Right now we are going to end up triggerring a
mount in the source directory (rooted at the automountpoint), not the
destination of the bind mount.  The reason for this is the kernel simply
generates a "missing packet" that contains the name of the directory being
looked up (the name here does not contain a full path, but rather a path
relative the automount root).

Put all of this together and you'll find that even if you could do a mount
--rbind of the /automountpoint, you wouldn't get the desired behaviour.

You're going to have to find a more creative way of achieving your goal, I'm afraid.

My suggestion is to close this bug as WONTFIX.  (Note that the fact that we
panic is a bad thing, but the behaviour is only triggerable in arguably broken
setups, and only by root.)

Comment 6 Rik van Riel 2005-05-17 22:53:45 EDT
One alternative solution could be to use autofs4 with multimounts.  Simply mount
whatever directories you want in a tree.

I am using this to automount a "custom" chroot for every user on one of the
systems I operate.  Every user shares the same /, with his/her own
/home/username mounted in there and their own /tmp, which is simply

The end result looks something like this:

# auto.chroot
# mount a chrooted users' directory tree
*       -fstype=bind    /       /srv/chroot/base \
                        /home/& /home/& \
                        /tmp    /home/&/tmp \
                        /dev/pts /dev/pts

This way I never automount anything that needs to follow submounts inside a bind
mounted directory.
Comment 8 Ernie Petrides 2005-05-18 14:15:09 EDT
Closing as WONTFIX as suggested in IT 69023.
Comment 13 Ernie Petrides 2005-09-21 20:44:34 EDT
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.3.EL).
Comment 16 Red Hat Bugzilla 2006-03-15 10:55:57 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.