Bug 154385 - Crash on relocated automounts with --bind
Summary: Crash on relocated automounts with --bind
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 168424
TreeView+ depends on / blocked
 
Reported: 2005-04-11 09:58 UTC by Bastien Nocera
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-15 15:55:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0144 0 qe-ready SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 7 2006-03-15 05:00:00 UTC

Description Bastien Nocera 2005-04-11 09:58:44 UTC
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
[crash]

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
lvm-mod   
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
(2.4.21-27.0.2.ELsmp/i686)
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 Jeff Moyer 2005-05-17 20:32:16 UTC
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
workaround.

Comment 5 Jeff Moyer 2005-05-17 22:26:40 UTC
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.)

-Jeff

Comment 6 Rik van Riel 2005-05-18 02:53:45 UTC
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
/home/username/tmp.

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 18:15:09 UTC
Closing as WONTFIX as suggested in IT 69023.

Comment 13 Ernie Petrides 2005-09-22 00:44:34 UTC
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 15:55:57 UTC
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.

http://rhn.redhat.com/errata/RHSA-2006-0144.html



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