potential race in FUSE's readdir() + releasedir()?

potential race in FUSE's readdir() + releasedir()?

[Nikolaus Rath]

Hello,

I am seeing something that to me looks like a race between FUSE's
readdir() and releasedir() handlers. On kernel 5.18, the FUSE daemon
seems to (ocasionally) receive a releasedir() request while a readdir()
request with the same `struct fuse_file_info *fi->fh` is still active
(i.e., the FUSE daemon hasn't sent a reply to the kernel for this yet).

Could this be a bug in the kernel? Or is there something else that could
explain this?

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: potential race in FUSE's readdir() + releasedir()?

[Miklos Szeredi]

On Sun, 3 Jul 2022 at 16:37, Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> Hello,
>
> I am seeing something that to me looks like a race between FUSE's
> readdir() and releasedir() handlers. On kernel 5.18, the FUSE daemon
> seems to (ocasionally) receive a releasedir() request while a readdir()
> request with the same `struct fuse_file_info *fi->fh` is still active
> (i.e., the FUSE daemon hasn't sent a reply to the kernel for this yet).
>
> Could this be a bug in the kernel? Or is there something else that could
> explain this?

Is there a log where this can be observed?

Thanks,
Miklos
\

Re: [fuse-devel] potential race in FUSE's readdir() + releasedir()?

[Nikolaus Rath]

On Jul 06 2022, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Sun, 3 Jul 2022 at 16:37, Nikolaus Rath <Nikolaus@rath.org> wrote:
>>
>> Hello,
>>
>> I am seeing something that to me looks like a race between FUSE's
>> readdir() and releasedir() handlers. On kernel 5.18, the FUSE daemon
>> seems to (ocasionally) receive a releasedir() request while a readdir()
>> request with the same `struct fuse_file_info *fi->fh` is still active
>> (i.e., the FUSE daemon hasn't sent a reply to the kernel for this yet).
>>
>> Could this be a bug in the kernel? Or is there something else that could
>> explain this?
>
> Is there a log where this can be observed?

Not so far, I haven't been able to reproduce it with debug logging
enabled.

The way that I'm inferring what's happening is from a crash due to
writing to freed memory. My fi->fh points to a malloc'ed area that is
free'd in releasedir(), and written to in readdir().


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«