Date: Tue, 23 Apr 2019 08:50:21 -0600 From: Alan Somers <asomers@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r346507 - in projects/fuse2/sys: kern sys Message-ID: <CAOtMX2iXc95_J=%2BWPsPZW-qKKNgn3ON%2BSPjHmMnv9cc3eJuBKA@mail.gmail.com> In-Reply-To: <20190423124657.GY12936@kib.kiev.ua> References: <201904212304.x3LN46Pt046728@repo.freebsd.org> <20190422171033.GX12936@kib.kiev.ua> <CAOtMX2iEedfvAN7okySeqOWREtaUG2%2BOi%2BfEQOGpo%2BRv92zTig@mail.gmail.com> <20190423124657.GY12936@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 23, 2019 at 6:47 AM Konstantin Belousov <kostikbel@gmail.com> wrote: > > On Mon, Apr 22, 2019 at 11:27:54AM -0600, Alan Somers wrote: > > On Mon, Apr 22, 2019 at 11:10 AM Konstantin Belousov > > <kostikbel@gmail.com> wrote: > > > > > > On Sun, Apr 21, 2019 at 11:04:06PM +0000, Alan Somers wrote: > > > > Author: asomers > > > > Date: Sun Apr 21 23:04:06 2019 > > > > New Revision: 346507 > > > > URL: https://svnweb.freebsd.org/changeset/base/346507 > > > > > > > > Log: > > > > fusefs: commit missing files from r346387 > > > > > > > > PR: 346357 > > > > Sponsored by: The FreeBSD Foundation > > > > > > > > Modified: > > > > projects/fuse2/sys/kern/kern_sig.c > > > > projects/fuse2/sys/sys/signalvar.h > > > > > > > > Modified: projects/fuse2/sys/kern/kern_sig.c > > > > ============================================================================== > > > > --- projects/fuse2/sys/kern/kern_sig.c Sun Apr 21 22:53:51 2019 (r346506) > > > > +++ projects/fuse2/sys/kern/kern_sig.c Sun Apr 21 23:04:06 2019 (r346507) > > > > @@ -929,6 +929,23 @@ osigreturn(struct thread *td, struct osigreturn_args * > > > > #endif > > > > #endif /* COMPAT_43 */ > > > > > > > > +/* Will this signal be fatal to the current process ? */ > > > > +bool > > > > +sig_isfatal(struct proc *p, int sig) > > > > +{ > > > > + intptr_t act; > > > > + > > > > + act = (intptr_t)p->p_sigacts->ps_sigact[_SIG_IDX(sig)]; > > > > + if ((intptr_t)SIG_DFL == act) { > > > > + int prop; > > > This is against style. > > > > > > > + > > > > + prop = sigprop(sig); > > > > + return (0 != (prop & (SIGPROP_KILL | SIGPROP_CORE))); > > > > + } else { > > > > + return (false); > > > > + } > > > > +} > > > Either your function lacks asserts about the owned locks, or it is racy. > > > > Good point. I'll add lock assertions. > > > > > > > > Said that, is the comment above describes the intent ? The > > > implementation is too naive. Just for example, blocked signals with > > > default disposition do not result in the termination. On the other hand, > > > blocked ignored traps cause immediate termination. > > > > I'm using this in a context where the signal has already been > > delivered and caught. So it can't be blocked, and it can't be a trap. > > > > > > > > Overall, I do not believe that it is possible to implement that without > > > duplicating the code of tdsendsignal() and trapsignal(), i.e. you should > > > additionally provide the originating context, besides a signal number. > > > > Do you still believe that even though it doesn't need to consider > > blocked signals and traps? > Generally yes, but lets see the specifics of the use. > > > > > > > > > What you are trying to do there ? > > > > It's in a situation where a syscall can't simply return EINTR or > > ERESTART. I need to do some extra work to interrupt the syscall (ask > > the FUSE daemon to interrupt the associated FUSE operation). If the > > signal will be fatal, then there's no point in waiting for the FUSE > > daemon to reply and I can simply return EINTR. However, if the signal > > is not fatal, then I need to wait to see if the FUSE daemon to > > acknowledge the interrupt or else complete the operation like normal. > In what context does the interruption happen ? Is it for a thread of the > fuse daemon, or normal process ? It's usually a normal process, but it could be another kernel thread, like aiod. It will never be the fuse daemon. > > Can you point out the specific fragment of code where the function is used ? Here's the function that uses it: https://svnweb.freebsd.org/base/projects/fuse2/sys/fs/fuse/fuse_ipc.c?view=markup#l429 -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iXc95_J=%2BWPsPZW-qKKNgn3ON%2BSPjHmMnv9cc3eJuBKA>