Messages in this thread |  | | From | Ivan Zuboff <> | Date | Sun, 16 May 2021 00:25:32 +0300 | Subject | lockf returns false-positive EDEADLK in multiprocess multithreaded environment |
| |
As a developer, I found a counter-intuitive behavior in lockf function provided by glibc and Linux kernel that is likely a bug.
In glibc, lockf function is implemented on top of fcntl system call: https://github.com/lattera/glibc/blob/master/io/lockf.c man page says that lockf can sometimes detect deadlock: http://manpages.ubuntu.com/manpages/xenial/man3/lockf.3.html Same with fcntl(F_SETLKW), on top of which lockf is implemented: http://manpages.ubuntu.com/manpages/hirsute/en/man3/fcntl.3posix.html
Deadlock detection algorithm in the Linux kernel (https://github.com/torvalds/linux/blob/master/fs/locks.c) seems buggy because it can easily give false positives. Suppose we have two processes A and B, process A has threads 1 and 2, process B has threads 3 and 4. When this processes execute concurrently, following sequence of actions is possible: 1. processA thread1 gets lockI 2. processB thread2 gets lockII 3. processA thread3 tries to get lockII, starts to wait 4. processB thread4 tries to get lockI, kernel detects deadlock, EDEADLK is returned from lockf function
Steps to reproduce this scenario (see attached file): 1. gcc -o edeadlk ./edeadlk.c -lpthread 2. Launch "./edeadlk a b" in the first terminal window. 3. Launch "./edeadlk a b" in the second terminal window.
What I expected to happen: two instances of the program are steadily working.
What happened instead: Assertion failed: (lockf(fd, 1, 1)) != -1 file: ./edeadlk.c, line:25, errno:35 . Error:: Resource deadlock avoided Aborted (core dumped)
Surely, this behavior is kind of "right". lockf file locks belongs to process, so on the process level it seems that deadlock is just about to happen: process A holds lockI and waits for lockII, process B holds lockII and is going to wait for lockI. However, the algorithm in the kernel doesn't take threads into account. In fact, a deadlock is not gonna happen here if the thread scheduler will give control to some thread holding a lock.
I think there's a problem with the deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. #include<unistd.h> #include<stdio.h> #include<stdlib.h> #include<fcntl.h> #include<errno.h> #include<pthread.h> #include<stddef.h> #include<stdint.h>
#define DIE(x)\ {\ fprintf(stderr, "Assertion failed: " #x " file: %s, line:%d, errno:%d ", __FILE__, __LINE__, errno); \ perror(". Error:");\ fflush(stdout);\ abort();\ } #define ASS(x) if (!(x)) DIE(x) #define ASS1(x) ASS((x) != -1) #define ASS0(x) ASS((x) == 0)
void * deadlocker(void *arg) { int fd = (int)(ptrdiff_t)arg; for (;;) { ASS1( lockf(fd, F_LOCK, 1) ); ASS1( lockf(fd, F_ULOCK, 1) ); } return NULL; }
int main(int argc, char * argv[]) { int fd1, fd2; ASS( argc >= 3 ); ASS1( fd1 = creat(argv[1], 0660) ); ASS1( fd2 = creat(argv[2], 0660) ); void * thrv; pthread_t thr1, thr2; ASS0( pthread_create(&thr1, NULL, deadlocker, (void *)(ptrdiff_t)fd2) ); ASS0( pthread_create(&thr2, NULL, deadlocker, (void *)(ptrdiff_t)fd1) ); ASS0( pthread_join(thr1, &thrv) ); ASS0( pthread_join(thr2, &thrv) ); return 0; }
|  |