Bug 127928 - creating a file in a 4755 directory hangs
creating a file in a 4755 directory hangs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Teigland
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-15 10:09 EDT by Christine Caulfield
Modified: 2015-10-21 07:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-30 18:06:53 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 Christine Caulfield 2004-07-15 10:09:48 EDT
Description of problem:

If an unprivileged user tries to create a file in a directory with
4755 protection, the process hangs as does anything else that tries to
access that directory.

This only happens when running GFS with the DLM, not gulm. A user also
reports it happens using gfs_quota but I haven't checked this

# mkdir /mnt/gfs/test
# chown user /mnt/gfs/test
# chmod 4755 /mnt/gfs/test
# su - user
$ touch /mnt/gfs/test/file

Looking in /proc/cluster/dlm_locks shows no waiting or converting locks.

How reproducible:
Always
Comment 1 Christine Caulfield 2004-07-15 10:39:31 EDT
This is the content of dlm_debug just afterwards.

test2 rq 3 980088 "       8             3e8"
test2 send lu 980088 to 3
test2 lu rep 980088 fr 3 0
test2 cv 5 980088 "       8             3e8"
test2 un 980088 ref 1 flg 4 nodeid 0/-1 "       8             3
test2 rq 3 9800fd "       8             3e8"
test2 send lu 9800fd to 3
test2 lu rep 9800fd fr 3 0
test2 cv 5 9800fd "       8             3e8"
test2 un 9800fd ref 1 flg 4 nodeid 0/-1 "       8             3
test2 rq 3 aa017c "       8             3e8"
test2 send lu aa017c to 3
test2 lu rep aa017c fr 3 0
test2 cv 5 aa017c "       8             3e8"
test2 un aa017c ref 1 flg 4 nodeid 0/-1 "       8             3
test2 rq 3 a002d5 "       8             3e8"
test2 send lu a002d5 to 3
test2 lu rep a002d5 fr 3 0
test2 cv 5 a002d5 "       8             3e8"
test2 un a002d5 ref 1 flg 4 nodeid 0/-1 "       8             3
test2 rq 3 a902bf "       8             3e8"
test2 send lu a902bf to 3
test2 lu rep a902bf fr 3 0

touch, and the dlm processes seem to be looping here.
Comment 2 Christine Caulfield 2004-07-15 10:53:54 EDT
This seems to have been caused by the recent lock_dlm changes. If I
roll back to Monday it works OK.
Comment 3 David Teigland 2004-07-16 03:21:45 EDT
it works for me after the following fixes:

Three different problems resulting from recent change to quit doing 
a convert-to-NL on a gfs unlock:

- dlm_unlock wasn't passing VALBLK flag to write lvb on unlock

- wake/complete for synchronous (internal) unlocks rather than gfs
callback

- lm_hold_lvb() wasn't preserving lvb contents since a dlm_unlock
would free the lkb and rsb.  Now if there's an lvb to preserve,
convert to NL on a lm_unlock() and do dlm_unlock on lm_unhold_lvb().
Comment 4 Corey Marthaler 2004-08-30 18:06:53 EDT
fix verified.
Comment 5 Kiersten (Kerri) Anderson 2004-11-16 14:13:06 EST
Updating version to the right level in the defects.  Sorry for the storm.

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