From: Nikolaus Rath <Nikolaus@rath.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
fuse-devel <fuse-devel@lists.sourceforge.net>,
miklos <mszeredi@redhat.com>
Subject: Re: [fuse-devel] potential race in FUSE's readdir() + releasedir()?
Date: Mon, 11 Jul 2022 09:33:40 +0100 [thread overview]
Message-ID: <878rp0xd3v.fsf@vostro.rath.org> (raw)
In-Reply-To: <CAJfpegvgWZcwP=M7hE44=jaKfmB2PXyzyodii63JZhGwVhaJHQ@mail.gmail.com> (Miklos Szeredi's message of "Wed, 6 Jul 2022 10:35:56 +0200")
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.«
prev parent reply other threads:[~2022-07-11 8:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-03 14:36 potential race in FUSE's readdir() + releasedir()? Nikolaus Rath
2022-07-06 8:35 ` Miklos Szeredi
2022-07-11 8:33 ` Nikolaus Rath [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rp0xd3v.fsf@vostro.rath.org \
--to=nikolaus@rath.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.