lsof icon indicating copy to clipboard operation
lsof copied to clipboard

LTlock fails on btrfs

Open nckx opened this issue 4 years ago • 12 comments

Hi!

The following test failure happens only when building on btrfs. Since everyone can easily reproduce that, and I'm clueless about lsof internals, I'll just leave this here:

Optional tests:
LTbigf ... OK
LTdnlc ... /tmp/guix-build-lsof-4.94.0.drv-0/lsof-4.94.0-checkout/tests found: 100.00%
           OK
LTlock ... lock mismatch: expected W, got " "
           lock mismatch: expected R, got " "
           lock mismatch: expected w, got " "
           lock mismatch: expected r, got " "
Failed tests: 1

make: *** [Makefile:118: opt] Error 1
command "make" "standard" "optional" failed with status 2

nckx avatar Mar 21 '21 11:03 nckx

Which distribution do you use?

masatake avatar Mar 21 '21 13:03 masatake

The bug isn't distribution-specific, but I use & first encountered it on Guix System.

nckx avatar Mar 21 '21 17:03 nckx

The bug isn't distribution-specific, but I use & first encountered it on Guix System.

Thank you. I was confused with btrfs with zfs. I will inspect this issue.

masatake avatar Mar 21 '21 17:03 masatake

Do you use btfs as your root file system? I would like to know the detail of the way to reproduce.

masatake avatar Mar 21 '21 17:03 masatake

Do you use btfs as your root file system?

Yes.

I would like to know the detail of the way to reproduce.

Sure! But note that / or not doesn't matter: simply create any btrfs file system and unpack & build lsof on it. Something like:

dd if=/dev/zero of=/tmp/img bs=1M count=512
mkfs.btrfs /tmp/img
mount -o loop /tmp/img /mnt
cd /mnt
git clone https://github.com/lsof-org/lsof
cd lsof
./Configure linux
make
cd tests
make opt
# LTlock should fail with the message above

nckx avatar Mar 21 '21 19:03 nckx

By the way, @masatake, the above is from memory, and was tried on an Ubuntu box (just to make sure the distro really doesn't matter after telling you it shouldn't :wink: ).

I don't have access to it now but if you still can't reproduce it, I can copy/paste my exact bash history tomorrow. It will be almost identical to what I wrote.

Thanks for responding so promptly!

nckx avatar Mar 21 '21 19:03 nckx

This report is about something else, but seems to exhibit the same failure: https://github.com/lsof-org/lsof/issues/61

nckx avatar Mar 21 '21 19:03 nckx

I found strange things about device minor number(s).

findmnt reports the minor number of mount point of btrfs is 67. stat reports the minor number of a file under the mount point of btrfs is 68. /proc/locks says the minor number of a locked file under the mount point of btrfs is 0x43 (== 67).

I guess lsof is confused with the mismatch of numbers.

[jet@living]/mnt% findmnt  -oTARGET,SOURCE,FSTYPE,MAJ:MIN /mnt
findmnt  -oTARGET,SOURCE,FSTYPE,MAJ:MIN /mnt
TARGET SOURCE     FSTYPE MAJ:MIN
/mnt   /dev/loop1 btrfs    0:67 
[jet@living]/mnt% stat /mnt/ /mnt/lsof/
stat /mnt/ /mnt/lsof/
  File: /mnt/
  Size: 8         	Blocks: 32         IO Block: 4096   directory
Device: 44h/68d	Inode: 256         Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:unlabeled_t:s0
Access: 2021-06-21 05:56:49.675987656 +0900
Modify: 2021-06-21 05:56:24.801910504 +0900
Change: 2021-06-21 05:56:24.801910504 +0900
 Birth: 2021-06-21 05:56:24.000000000 +0900
  File: /mnt/lsof/
  Size: 1196      	Blocks: 0          IO Block: 4096   directory
Device: 44h/68d	Inode: 257         Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/     jet)   Gid: ( 1000/     jet)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2021-06-21 06:27:15.316102351 +0900
Modify: 2021-06-21 06:27:12.934091866 +0900
Change: 2021-06-21 06:27:12.934091866 +0900
 Birth: 2021-06-21 05:56:24.801910504 +0900
object_r:unlabeled_t:s0
Access: 2021-06-21 06:25:43.109696511 +0900
Modify: 2021-06-21 06:25:43.109696511 +0900
Change: 2021-06-21 06:25:43.109696511 +0900
 Birth: 2021-06-21 06:25:43.109696511 +0900
[jet@living]/mnt% stat /mnt/lsof/tests/config.LTlock2630449 
stat /mnt/lsof/tests/config.LTlock2630449 
  File: /mnt/lsof/tests/config.LTlock2630449
  Size: 2048      	Blocks: 8          IO Block: 4096   regular file
Device: 44h/68d	Inode: 842         Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/     jet)   Gid: ( 1000/     jet)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2021-06-21 06:25:43.109696511 +0900
Modify: 2021-06-21 06:25:43.109696511 +0900
Change: 2021-06-21 06:25:43.109696511 +0900
 Birth: 2021-06-21 06:25:43.109696511 +0900
[jet@living]/mnt% grep 842 /proc/locks 
grep 842 /proc/locks 
17: POSIX  ADVISORY  WRITE 2630449 00:43:842 0 EOF

masatake avatar Jun 20 '21 21:06 masatake

I guess this is something to do with the subvolume feature of btrfs.

masatake avatar Jun 20 '21 21:06 masatake

As the test case shows lsof cannot report the lock information (RW) for a locked file on btrfs correctly.

masatake avatar Jun 20 '21 21:06 masatake

https://www.spinics.net/lists/linux-btrfs/msg09044.html

masatake avatar Jun 21 '21 09:06 masatake