nlmsvc_lock calls nlmsvc_create_block to create a nlm_block struct but never initializes the fl_link and fl_block list_head structs that it contains. The result is that when they are used list_empty() thinks they have other locks chained in and locks_delete_block tries to use the null pointers (next/prev). After nlmsvc_create_block is called to allocate a new nlm_block, there needs to be: INIT_LIST_HEAD(&block->b_call.a_args.lock.fl.fl_link); INIT_LIST_HEAD(&block->b_call.a_args.lock.fl.fl_block); In nlmsvc_lock (2.4.0-test7 kernel): /* If we don't have a block, create and initialize it. Then * retry because we may have slept in kmalloc. */ if (block == NULL) { dprintk("lockd: blocking on this lock (allocating).\n"); if (!(block = nlmsvc_create_block(rqstp, file, lock, cookie))) return nlm_lck_denied_nolocks; #if 1 /* Must init the file_lock list_head fields or we choke trying to use them (they are expected to be circular lists... never 0). */ INIT_LIST_HEAD(&block->b_call.a_args.lock.fl.fl_link); INIT_LIST_HEAD(&block->b_call.a_args.lock.fl.fl_block); #endif goto again; } /* Append to list of blocked */ nlmsvc_insert_block(block, NLM_NEVER); if (!list_empty(&block->b_call.a_args.lock.fl.fl_block)) { /* Now add block to block list of the conflicting lock if we haven't done so. */ dprintk("lockd: blocking on this lock.\n"); posix_block_lock(conflock, &block->b_call.a_args.lock.fl); }
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/