Bug 98346 - (FS)autmount/symlink behavior change in 2.4.20-18.9 kernel
(FS)autmount/symlink behavior change in 2.4.20-18.9 kernel
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-01 10:49 EDT by Paul Raines
Modified: 2007-04-18 12:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Raines 2003-07-01 10:49:37 EDT
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 11:41:13 EDT
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/

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