Date: Wed, 24 Apr 2019 19:55:40 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r346640 - in projects/fuse2/sys: fs/fuse kern Message-ID: <20190424165540.GE12936@kib.kiev.ua> In-Reply-To: <CAOtMX2hYZ4haMUbQ9rceycbaVwoJ=3fQHmKT69%2BG_C1mcT3K5w@mail.gmail.com> References: <201904241554.x3OFsIjw024483@repo.freebsd.org> <20190424162837.GD12936@kib.kiev.ua> <CAOtMX2hYZ4haMUbQ9rceycbaVwoJ=3fQHmKT69%2BG_C1mcT3K5w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 24, 2019 at 10:41:57AM -0600, Alan Somers wrote: > On Wed, Apr 24, 2019 at 10:28 AM Konstantin Belousov > <kostikbel@gmail.com> wrote: > > > > On Wed, Apr 24, 2019 at 03:54:18PM +0000, Alan Somers wrote: > > > Author: asomers > > > Date: Wed Apr 24 15:54:18 2019 > > > New Revision: 346640 > > > URL: https://svnweb.freebsd.org/changeset/base/346640 > > > > > > Log: > > > fusefs: interruptibility improvements suggested by kib > > > > > > * Block stop signals in fticket_wait_answer > > This might be ok, but consider using VFCF_SBDRY. > > Like the way it's used in nfs_vfsops? NFS just sets the flag in VFS_SET(). Then all VOPs and VFS methods get implicit sbdry setting around them. Of course advisory locks require some more care. > > > > > > * Hold ps_mtx while checking signal disposition > > This part is pointless, as explained before. > > > > > * style(9) changes > > And sig_isfatal() is still there, which I consider an architectural bug. > > Try to think of it as a protocol bug instead. It's not ideal, but > this is the way that FUSE is supposed to work. BTW, there actually is > a intr/nointr mount option, but it's implemented in userland within > libfuse. For FreeBSD we could patch libfuse to implement it > kernel-side instead. But fixing the multi-threaded signal delivery > logic would require a version of msleep that would only catch fatal > signals. Is there such a thing? No, there is no such thing, and I noted to you that this approach simply does not work for mt programs. If one thread of mt process is inside fuse, and another thread decided to exit process (either by exit, or due to trap, or due to the 'fatal' signal action), most likely things would hang until your machinery finishes the request. Again, I strongly suggest to not fight against the signal handling code and do what other filesystems already agreed upon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190424165540.GE12936>