readdirplus skips entries when interrupted by signal

[rfjakob]

If a process receives a signal while in a readdirplus call, one directory entry is skipped. This is can be reproduced against passthrough_fh.c, but also against the go-fuse based filesystems (loopback, zipfs, gocryptfs), suggesting a kernel bug.

Reproducer: ls-count.c

Example output against passthrough_fh.c mounted on /tmp/mnt:

$ ./ls-count /tmp/mnt
ls-count: counts do not match: 28 vs 27

strace of ls-count:

open("mnt", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
getdents(3, /* 1 entries */, 32768)     = 32
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=1991720024, ptr=0x7f9176b73c58}} ---
rt_sigreturn({mask=[]})                 = 32
getdents(3, /* 26 entries */, 32768)    = 672
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
write(2, "ls-count: counts do not match: 2"..., 40ls-count: counts do not match: 28 vs 27
) = 40

passthrough_fh -d output:

unique: 2187, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 13520
opendir flags: 0x18800 /
   opendir[139877622483792] flags: 0x18800 /
   unique: 2187, success, outsize: 32
unique: 2188, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 13520
getattr[NULL] /
   unique: 2188, success, outsize: 120
unique: 2189, opcode: READDIRPLUS (44), nodeid: 1, insize: 80, pid: 13520
readdirplus[139877622483792] from 0
   unique: 2189, success, outsize: 4032
unique: 2190, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 13520
readdir[139877622483792] from 1140798899870940157
   unique: 2190, success, outsize: 864
unique: 2191, opcode: READDIR (28), nodeid: 1, insize: 80, pid: 13520
readdir[139877622483792] from 9223372036854775807
   unique: 2191, success, outsize: 16
unique: 2192, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0
releasedir[139877622483792] flags: 0x0
   unique: 2192, success, outsize: 16

I find the go-fuse debug output a little easier to read, because the direntry offsets are simple counters:

go-fuse debug output

READDIRPLUS, NodeId: 1. data: {Fh 3 off 0 sz 4096  L 0 DIRECTORY,NONBLOCK,0x8000} 
*** SIGVTALRM ---> user app gets 1 dir entry ***
READDIRPLUS, NodeId: 1. data: {Fh 3 off 2 sz 4096  L 0 DIRECTORY,NONBLOCK,0x8000} 
*** kernel continues at offset 2  -----^^
*** should continue at 1
READDIRPLUS, NodeId: 1. data: {Fh 3 off 27 sz 4096  L 0 NONBLOCK,DIRECTORY,0x8000} 
READDIRPLUS, NodeId: 1. data: {Fh 3 off 28 sz 4096  L 0 DIRECTORY,NONBLOCK,0x8000} 

Downstream bug: hanwen/go-fuse#191

[Nikratio]

Thanks for the detailed report, very much appreciated!

However, as far as I can tell, this is a problem with the FUSE Linux kernel module. This GitHub project is for libfuse, the FUSE userspace counterpart. Reporting kernel issues here will therefore generally not result in much of a response, let alone in them being fixed.

The FUSE kernel module is maintained in the mainline linux kernel, so the best way to get issues addressed is to raise them on the Linux kernel mailing lists, linux-kernel and linux-fsdevel. It would be great if you could report the issue there.

I'll close this issue for now - please feel free to re-open if I misunderstood the problem.

(While we do keep track of some kernel issues in these tracker as well, these are selected high-impact issues that have someone acting as a liaison with the kernel developers to ensure that the issue is kept up-to-date).

[rfjakob]

Understood, will post to lkml. Progress will be tracked in hanwen/go-fuse#191