Description of problem: If I create > ~ 2930 locks dlm_tool lockdump either displays garbage data or nothing at all. Releasing some of the locks "fixes" the issue. Version-Release number of selected component (if applicable): cman-2.0.80-1.el5 How reproducible: Every time Steps to Reproduce: 1. grab more than 3000 locks 2. dlm_tool lockdump myns
As Dave suggested, a cat of the _locks file in /sys/kerne/debug/dlm shows the issue: [root@marathon-01 dlm]# pwd /sys/kernel/debug/dlm [root@marathon-01 dlm]# cat default_locks cat: default_locks: Cannot allocate memory If you run dlm_tool lockdump default when the above happens you get: [root@marathon-01 dlm]# dlm_tool lockdump default invalid debugfs line 0: id nodeid remid pid xid exflags flags sts grmode rqmode time_ms r_nodeid r_len r_name The following patch has dlm_tool report an error of the initial fgets returns an error rather than printing out either the first line of the file or garbage: [root@marathon-01 dlm_tool]# ./dlm_tool lockdump default can't read /sys/kernel/debug/dlm/default_locks: Cannot allocate memory [root@marathon-01 dlm_tool]# --- ../main.c 2008-03-14 14:56:03.000000000 -0500 +++ main.c 2008-03-14 15:16:13.000000000 -0500 @@ -332,7 +332,12 @@ } /* skip the header on the first line */ - fgets(line, LOCK_LINE_MAX, file); + if (!fgets(line, LOCK_LINE_MAX, file)) { + if (!feof(file)) { + fprintf(stderr, "can't read %s: %s\n", path, strerror(errno)); + } + return; + } while (fgets(line, LOCK_LINE_MAX, file)) { rv = sscanf(line, "%x %d %x %u %llu %x %x %hhd %hhd %hhd %u %d %d", '
The reason I've not done anything with this is that I tested with many times this number of locks and never had a problem dumping them all. Because this is only a cosmetic issue, it's not worth the effort of getting the patch into RHEL and I'm going to just drop it.