Bug 98346

Summary: (FS)autmount/symlink behavior change in 2.4.20-18.9 kernel
Product: [Retired] Red Hat Linux Reporter: Paul Raines <raines>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:41:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Raines 2003-07-01 14:49:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
access()'s behavior in the 2.4.20-18.9 kernel has changed in very bad way. It
did not do this in 2.4.20-9

When one does a 'rm -rf' on a directory structure and it encounters a symlink
that points to an automounted area and the server which the automouter will try
to mount is down, the rm will hang forever as for some reason to remove this
sysmlink, rm now wants to mount what it pointed to.

By comparing straces of the same rm process with the machine booted under
2.4.20-18.9 and 2.4.20-9 I see the strace process on 2.4.20-18.9 hang on a
system access call on the symlink.



Version-Release number of selected component (if applicable):
2.4.20-18.9smp

How reproducible:
Always

Steps to Reproduce:
1. create a directory and put a symlink to a automounted volume whose server is
currently down in it
2. try a 'rm -rf' on the directory containing the link

    

Actual Results:  rm process will hang and one will find a mount process hung in
the process list that is trying to mount the volume symlinked to.



Expected Results:  It should remove the symlink without generating an automount
event

Additional info:

prime is currently a down server with an entry in autofs

# mkdir /space.test
# ln -s /autofs/space/prime_001 /space.test/1
# strace /bin/rm -rf /space.test

Booted on a 2.4.20-9 kernel, this completes fine.  On a 2.4.20-18.9 kernel it
hangs and one finds a mount attempt by the automounter in the process table

# strace /bin/rm -rf /space.test
execve("/bin/rm", ["/bin/rm", "-rf", "/space.test"], [/* 25 vars */]) = 0
uname({sys="Linux", node="icebox", ...}) = 0
brk(0)                                  = 0x804f728
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=86264, ...}) = 0
old_mmap(NULL, 86264, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)                                = 0
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220W\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1536292, ...}) = 0
old_mmap(0x42000000, 1261416, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000
old_mmap(0x4212f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x12f000) = 0x4212f000
old_mmap(0x42132000, 8040, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42132000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4002d000
set_thread_area({entry_number:-1 -> 6, base_addr:0x4002d280, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40017000, 86264)               = 0
brk(0)                                  = 0x804f728
brk(0x8050728)                          = 0x8050728
brk(0)                                  = 0x8050728
brk(0x8051000)                          = 0x8051000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=30301680, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4002e000
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0
brk(0)                                  = 0x8051000
brk(0x8052000)                          = 0x8052000
brk(0)                                  = 0x8052000
brk(0x8053000)                          = 0x8053000
lstat64("/space.test", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/space.test", W_OK)             = 0
unlink("/space.test")                   = -1 EISDIR (Is a directory)
open(".", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3
lstat64("/space.test", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/space.test")                    = 0
lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
brk(0)                                  = 0x8053000
brk(0x8054000)                          = 0x8054000
getdents64(4, /* 3 entries */, 4096)    = 72
lstat64("1", {st_mode=S_IFLNK|0777, st_size=23, ...}) = 0
access("1", W_OK

Comment 1 Bugzilla owner 2004-09-30 15:41:13 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/