All of lore.kernel.org
 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 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.