linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "YoungJun.Park" <her0gyugyu@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alex Murray <alex.murray@canonical.com>, linux-fsdevel@vger.kernel.org
Subject: Re: Re: question about fuse livelock situation
Date: Wed, 18 Jan 2023 23:05:28 -0800	[thread overview]
Message-ID: <20230119070528.GA1337007@ubuntu> (raw)
In-Reply-To: <CAJfpegugtmfjkW9ysDobNJGZM=G0Y_wrK1uHwANjSnKX1K++SA@mail.gmail.com>

On Wed, Aug 31, 2022 at 11:58:50AM +0200, Miklos Szeredi wrote:
> On Tue, 30 Aug 2022 at 03:58, 박영준 <her0gyugyu@gmail.com> wrote:
> >
> > I found fuse livelock situation and report it for possibility of problem.
> >
> > [Environment]
> > 22.04 5.15.0-43-generic ubuntu kernel.
> > ntfs-3g version ntfs-3g 2021.8.22 integrated FUSE 28 - Third
> > Generation NTFS Driver
> >
> > [Problem]
> > I bumped on livelock and analyze it. and concluded that it is needed
> > to be fixed.
> > it happends when 3 operation concurrently progressing.
> >
> > 1) usb detach by user. and kernel detect it.
> > 2) mount.ntfs umount request & device release operation
> > 3) pool-udisksd umount operation.
> >
> > [Conclusion]
> > 1. mounted target device file must be released after /dev/fuse
> > release. it makes deadlocky scenario.
> 
> Shouldn't this be reported to ntfs-3g developers then?
> 
> Thanks,
> Miklos

I reported it ntfs-3g and ubuntu bug report channel. 
ntfs-3g does not respond and ubuntu bug report channel response it like below.
(If you want a detail scenario flow picture, calltack etc check the link 
https://github.com/tuxera/ntfs-3g/issues/56)

> Hi

> Thanks for reporting this issue - in general it is better to report bugs
> via launchpad than email (e.g. by running the following command (without
> the quotation marks) in a terminal: "ubuntu-bug ntfs-3g" or by
> https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+filebug)

> I notice you also appear to have reported this to the upstream nfts-3g
> project at https://github.com/tuxera/ntfs-3g/issues/56 but have had no
> response.

> However, my initial thoughts when looking at this is that it appears you
> can trigger a livelock within the kernel from an unprivileged user in
> userspace - as such I wonder if this is a bug in the FUSE subsystem
> within the Linux kernel and hence whether it should be reported to the
> upstream kernel developers as well? As per
> https://www.kernel.org/doc/html/v4.15/admin-guide/reporting-bugs.html it
> would appear that this should be reported to the following email
> addresses (assuming this is a real kernel bug rather than a bug within
> the ntfs-3g userspace project):

> $ ./scripts/get_maintainer.pl fs/fuse/fuse_i.h
> Miklos Szeredi <miklos@szeredi.hu> (maintainer:FUSE: FILESYSTEM IN USERSPACE)
> linux-fsdevel@vger.kernel.org (open list:FUSE: FILESYSTEM IN USERSPACE)
> linux-kernel@vger.kernel.org (open list)

> Thanks,
> Alex

Could you explan why it shoulde be fixed in userspace?
then I try to fix this issue and to report it one more based on your comment.

Thanks,
YoungJun park. 


  reply	other threads:[~2023-01-19  7:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  1:58 question about fuse livelock situation 박영준
2022-08-31  9:58 ` Miklos Szeredi
2023-01-19  7:05   ` YoungJun.Park [this message]
2023-01-23 13:19     ` Miklos Szeredi

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=20230119070528.GA1337007@ubuntu \
    --to=her0gyugyu@gmail.com \
    --cc=alex.murray@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).