[Kernel-packages] [Bug 1926481] Re: lockf returns false-positive EDEADLK in multiprocess multithreaded environment
Posted to more specific mailing list: linux-fsdevel.vger.kernel.org https://lore.kernel.org/linux-fsdevel/cal-cveifotfbyrfocb0yeyor+sctpwo_2__49tapronhr+t...@mail.gmail.com/T/#u -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname:
[Kernel-packages] [Bug 1926481] Re: lockf returns false-positive EDEADLK in multiprocess multithreaded environment
Posted info to LKML with topic "lockf returns false-positive EDEADLK in multiprocess multithreaded environment": https://lkml.org/lkml/2021/5/15/287 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] WifiSyslog.txt
apport information ** Attachment added: "WifiSyslog.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493127/+files/WifiSyslog.txt ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
[Kernel-packages] [Bug 1926481] UdevDb.txt
apport information ** Attachment added: "UdevDb.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493126/+files/UdevDb.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64 UpgradeStatus:
[Kernel-packages] [Bug 1926481] ProcModules.txt
apport information ** Attachment added: "ProcModules.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493125/+files/ProcModules.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] ProcInterrupts.txt
apport information ** Attachment added: "ProcInterrupts.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493124/+files/ProcInterrupts.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] ProcCpuinfoMinimal.txt
apport information ** Attachment added: "ProcCpuinfoMinimal.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493123/+files/ProcCpuinfoMinimal.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux
[Kernel-packages] [Bug 1926481] ProcCpuinfo.txt
apport information ** Attachment added: "ProcCpuinfo.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493122/+files/ProcCpuinfo.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] Lsusb-v.txt
apport information ** Attachment added: "Lsusb-v.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493121/+files/Lsusb-v.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] Lspci-vt.txt
apport information ** Attachment added: "Lspci-vt.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493120/+files/Lspci-vt.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] Lspci.txt
apport information ** Attachment added: "Lspci.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493119/+files/Lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64 UpgradeStatus:
[Kernel-packages] [Bug 1926481] CurrentDmesg.txt
apport information ** Attachment added: "CurrentDmesg.txt" https://bugs.launchpad.net/bugs/1926481/+attachment/5493118/+files/CurrentDmesg.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: Confirmed Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 ноя 12 09:53 seq crw-rw 1 root audio 116, 33 ноя 12 09:53 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CasperMD5CheckResult: pass DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-07-22 (280 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M MachineType: VMware, Inc. VMware Virtual Platform Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 RelatedPackageVersions: linux-restricted-modules-5.4.0-42-generic N/A linux-backports-modules-5.4.0-42-generic N/A linux-firmware1.187.2 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-42-generic x86_64
[Kernel-packages] [Bug 1926481] Re: lockf returns false-positive EDEADLK in multiprocess multithreaded environment
apport information ** Tags added: apport-collected uec-images ** Description changed: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + --- + ProblemType: Bug + AlsaDevices: + total 0 + crw-rw 1 root audio 116, 1 ноя 12 09:53 seq + crw-rw 1 root audio 116, 33 ноя 12 09:53 timer + AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' + ApportVersion: 2.20.11-0ubuntu27.4 + Architecture: amd64 + ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' + AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: + CasperMD5CheckResult: pass + DistroRelease: Ubuntu 20.04 + InstallationDate: Installed on 2020-07-22 (280 days ago) + InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Release amd64 (20200423) + IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' + Lsusb: + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + Bus 002 Device 004: ID 0a89:0030 Aktiv Rutoken ECP + Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub + Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse + Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + Lsusb-t: + /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M + |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M + |__ Port 1: Dev 4, If 0, Class=Chip/SmartCard, Driver=, 12M + /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M + MachineType: VMware, Inc. VMware Virtual Platform + Package: linux (not installed) + PciMultimedia: + + ProcEnviron: + TERM=xterm + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=ru_RU.UTF-8 + SHELL=/bin/bash + ProcFB: 0 svgadrmfb + ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-42-generic root=UUID=1d0fe562-8128-4922-836e-b0a384fc5054 ro maybe-ubiquity + ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44 + RelatedPackageVersions: + linux-restricted-modules-5.4.0-42-generic N/A + linux-backports-modules-5.4.0-42-generic N/A + linux-firmware1.187.2 + RfKill: Error: [Errno 2] No such file or directory: 'rfkill' + Tags: focal uec-images + Uname: Linux 5.4.0-42-generic x86_64 + UpgradeStatus: No upgrade log present (probably fresh install) + UserGroups: N/A + _MarkForUpload: True + dmi.bios.date: 09/21/2015 + dmi.bios.vendor: Phoenix Technologies LTD + dmi.bios.version: 6.00 + dmi.board.name: 440BX Desktop Reference Platform + dmi.board.vendor: Intel Corporation + dmi.board.version: None + dmi.chassis.asset.tag: No Asset Tag +
[Kernel-packages] [Bug 1926481] [NEW] lockf returns false-positive EDEADLK in multiprocess multithreaded environment
Public bug reported: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications. # lsb_release -rd Description:Ubuntu 20.04.1 LTS Release:20.04 # uname -a Linux test-x64-ub20 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Attachment added: "test to reproduce the problem" https://bugs.launchpad.net/bugs/1926481/+attachment/5493082/+files/edeadlk.c -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1926481 Title: lockf returns false-positive EDEADLK in multiprocess multithreaded environment Status in linux package in Ubuntu: New Bug description: 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 (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 first terminal window. 3. Launch "./edeadlk a b" in second terminal window. What I expected to happen: two instances of the program is 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, algorithm in kernel doesn't take threads into account. In fact, deadlock is not gonna happen here if thread scheduler will give control to some thread holding a lock. I think there's a problem with deadlock detection algorithm because it's overly pessimistic, which in turn creates problems -- lockf errors in applications.
