Bug 101451 - autofs4 does not work on x64_64
Summary: autofs4 does not work on x64_64
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: autofs   
(Show other bugs)
Version: 1.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-01 08:26 UTC by Albert Fluegel
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-08 18:15:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Albert Fluegel 2003-08-01 08:26:38 UTC
Description of problem:

Admittedly this is not really a bug, it's just that autofs4
is not working on 64-Bit architectures not covered by the auto_fs.h
header file. I guess autofs3 has been fixed appropriately, but
we really need autofs4 cause of hierarchical automounts. The
problem is, that the type of the wait queue token used to identify
threads waiting for a certain mount is a 32 unsigned in the kernel,
but when building autofs-4.0.XY e.g. on a AMD opteron the type will
be a 64 bit unsigned. I don't know, how it is achieved, that the
x86_64 kernel uses a 32 bit type, cause it should use the same
header file during build (?!?). ANyway here is the problematic
snippet from the kernel's auto_fs.h header:

#if !defined(__alpha__) && !defined(__ia64__)
typedef unsigned int autofs_wqt_t;
typedef unsigned long autofs_wqt_t;

i have no idea, why a long type has ever been specified here.
In my opinion this is a classical case for e.g. u_int32_t
defined in types.h . If a variable should always be 32 bit
unsigned, the appropriate type definition that is available
anyway can be used.
I built autofs-4.0.0pre10 applying a hack to define the
autofs_wqt_t using the cpp adding -Dautofs_wqt_t=unsigned
to the CFLAGS in Makefile.rules , this is a hack of course,
but it proofs, that afterwards the automount daemon works.

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

How reproducible:

Steps to Reproduce:
1. build autofs4 daemon on opteron
2. start automount daemon with a trivial map e.g. for the mountpoint /mnt/test
3. enter or ls a subdirectory of /mnt/test specified in the map
Actual results:
process hangs (cause the daemon waits for 4 more bytes to be shipped
from the kernel as wait queue token)

Expected results:
automounter daemon mounts the directory and contents are listed or
directory changed

Additional info:

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