Project

General

Profile

Actions

Bug #2364

closed

panic: lockmgr: locking against myself

Added by marino over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/09/2012
Due date:
% Done:

0%

Estimated time:

Description

This is an easily repeatable panic.
Edit a file with size > 4096 bytes using /usr/pkg/bin/heme, and save.
boom

http://leaf.dragonflybsd.org/~marino/core/core.locking_against_myself.txt

Seen on i386 on Virtualbox but already reproduced independently by vrinivas.
DragonFly a4d7a8c-DEVELOPMENT #4: Mon May 7 18:55:28 CEST 2012 root@:/usr/obj/usr/src/sys/GENERIC

core dump located in leaf ~marino/crash


Related issues 2 (0 open2 closed)

Related to Bug #2336: 3.0.3 catchall Resolved03/26/2012

Actions
Related to Bug #2402: Showstopper panics for Release 3.2Closedtuxillo08/15/2012

Actions
Actions #1

Updated by vsrinivas over 10 years ago

https://gist.github.com/2660254 is a small testcase for this bug.

Actions #2

Updated by alexh over 10 years ago

Link to the gist seems to be gone. I found the content in google's webcache:

/* dd if=/dev/zero of=test bs=1 count=7168 */
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

main(argc, argv)
int argc;
char *argv[]; {
int fd;
int backup_fd;
char *mmap_region;
struct stat sb;
char buf8192;
int i0, i;

fd = open(argv[1], O_RDWR);
fstat(fd, &sb);
mmap_region = mmap(NULL, 4096 * 2, PROT_READ|PROT_WRITE,MAP_PRIVATE,
fd, 0);
mmap_region[4] = 'b';
lseek(fd, 0, SEEK_SET);
write(fd, mmap_region, sb.st_size);
munmap(mmap_region, 8192);
}
Actions #3

Updated by dillon over 10 years ago

  • Status changed from New to In Progress

Here is a better test program, works for x86-64 or i386. The size of the file depends on how UFS was formatted. The file must be such that the last block is a fragment which covers less than a page. We then issue a write that hits that fragment. The bread() of the buffer brings in the VM page but the VM page's valid bits are not fully set. This then causes the copyin or copyout to fault, creating the double-lock.

/* * Must be one fragment less than a page. Typical UFS filesystems * are configured 1K/8K or 2K/16K. Larger ones tend to be configured * 2K/16K. Use 7168 for 1K/8K and 6144 for 2K/16K * * dd if=/dev/zero of=test bs=6144 count=1 * dd if=/dev/zero of=test bs=7168 count=1
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>

main(int argc, char **argv) {
int fd;
int backup_fd;
char *mmap_region;
char buf8192;
int i0, i;
ssize_t n;

fd = open(argv[1], O_RDWR);
mmap_region = mmap(NULL, 16384 * 2,
PROT_READ|PROT_WRITE,MAP_PRIVATE,
fd, 0);
fprintf(stderr, "%d %p\n", fd, mmap_region);
#if 1
madvise(mmap_region, 16384 * 2, MADV_RANDOM);
madvise(mmap_region, 16384 * 2, MADV_INVAL);
#endif
mmap_region[4] = 'b';
lseek(fd, 0, SEEK_SET);
n = write(fd, mmap_region, 4096+2048);
printf("write n=%zd\n", n);
munmap(mmap_region, 16384 * 2);
}
Actions #4

Updated by dillon over 10 years ago

  • Status changed from In Progress to Closed

Fixed in commit 44480e310a5e2fdec131e9154d62ac8fb0f011a9. However, there are still potential deadlock situations due to the same recursion VM fault issue that have not yet been resolved.

Actions

Also available in: Atom PDF