All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	linux-fsdevel@vger.kernel.org,
	Sahitya Tummala <stummala@codeaurora.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [fuse-devel] Reading from fuse pipe fails with EBADFD
Date: Mon, 31 Dec 2018 10:56:30 +0000	[thread overview]
Message-ID: <878t066k2p.fsf@vostro.rath.org> (raw)
In-Reply-To: <87lg4bncnz.fsf@vostro.rath.org> (Nikolaus Rath's message of "Wed, 26 Dec 2018 22:30:56 +0000")

On Dec 26 2018, Nikolaus Rath <Nikolaus@rath.org> wrote:
>>> >> > When testing FUSE under heavy load, I am occasionally getting EBADFD
>>> >> > errors when reading from the fuse pipe.
>>> >
>>> > EBADFD or EBADF?
>>>
>>> EBADF ("Bad file descriptor"), sorry.
>>
>> Can you run the thing with "strace -f  ..."?
>
> Apologies for the delayed response. I have been trying to reproduce this
> but have instead run into another problem: the *client* getting spurious
> EBADF warnings. I am not sure if this is related or unrelated, and it
> has been hard to debug because it does not happen under strace:
[..]

I believe I have figured it out. I was mistakenly assuming that the bad
file descriptor was the fuse pipe - but it was actually the target file
descriptor (I managed to completely forget that splice works on two file
descriptors).

The root cause was mistakenly closing a file descriptor twice and not
checking the return value. Because of the missing return value check,
the error went unnoticed almost all the time - except when a different
thread managed to re-use the fd for different purposes between the first
and second close.

Apologies for taking everyone's time for what was actually a filesystem
bug.


Best,
-Nikolaus

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

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

      reply	other threads:[~2018-12-31 10:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27 20:26 Reading from fuse pipe fails with EBADFD Nikolaus Rath
2018-12-04  9:03 ` Nikolaus Rath
2018-12-04  9:10   ` Miklos Szeredi
2018-12-04 19:02     ` [fuse-devel] " Nikolaus Rath
2018-12-10  9:19       ` Miklos Szeredi
2018-12-26 22:30         ` Nikolaus Rath
2018-12-31 10:56           ` 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=878t066k2p.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 \
    --cc=stummala@codeaurora.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.