From owner-svn-src-projects@freebsd.org Tue Sep 3 14:07:25 2019 Return-Path: Delivered-To: svn-src-projects@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F844DDA79 for ; Tue, 3 Sep 2019 14:07:25 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N80X3nnJz4QZ1; Tue, 3 Sep 2019 14:07:24 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 90A3F1B5D2; Tue, 3 Sep 2019 14:06:38 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id C6EB7677A; Tue, 23 Apr 2019 15:50:31 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36C5676F18; Tue, 23 Apr 2019 15:50:31 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0E069674F; Tue, 23 Apr 2019 15:50:31 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 75FFE674D for ; Tue, 23 Apr 2019 15:50:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2824876F0F; Tue, 23 Apr 2019 15:50:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f45.google.com with SMTP id v1so3368250lfg.5; Tue, 23 Apr 2019 08:50:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+aQR1GTiSTjvWgxnpY/a4BYaEFx8FqMWltErzZuT3nM=; b=LIYJK0NFn7DGWr54+4yUcZ6O0bQMUSg85YIoLaXUy+Ap8LRhmtgS8IIjuuOIhJu78F NMFBNqWJUs784rb0zZhJv87ac++xJempDtwGX+IBHkgI8K9Lsk1POE9WHpbYm3BrYHVM Q2m/IgQ0K60HLOB/VXb41OlZNv7ngroW0nolpavvZIcGTv8XM6iuNWSSR7iMRT86Slhi DjT8jUBzDr6u8qOXI5253DjTD7CP3uVzYnSYLSMwU0z6/2x3kFasRsSilB7EGt05UO7c gah8ukr3I+1WdRPTSf+0UjKG9fQZmhAJMqjYcZ6ZGjoWoBNx5TA/vDitPAmEHiws3qxr asaA== X-Gm-Message-State: APjAAAW+Uc8waghXUgH21vryc4e7OBNfjWXDWKah5HzBV4mJ6BY1tZI2 /apUfk/BmZL0lVkcWOxS6LA+gad8HQdrC5Z5ckxENy9OO8w= X-Google-Smtp-Source: APXvYqwpqMW3rh1IPSELn4G0gRuaeWRH8/kji8lbVMuqrTr8ElOgBlf5PhL9MdT+Rj0kEgWajagi4o1Lgb1vLAoGQnM= X-Received: by 2002:ac2:598b:: with SMTP id w11mr14720948lfn.62.1556031032607; Tue, 23 Apr 2019 07:50:32 -0700 (PDT) MIME-Version: 1.0 References: <201904212304.x3LN46Pt046728@repo.freebsd.org> <20190422171033.GX12936@kib.kiev.ua> <20190423124657.GY12936@kib.kiev.ua> In-Reply-To: <20190423124657.GY12936@kib.kiev.ua> From: Alan Somers Message-ID: Subject: Re: svn commit: r346507 - in projects/fuse2/sys: kern sys To: Konstantin Belousov Cc: src-committers , svn-src-projects@freebsd.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 36C5676F18 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:07:25 -0000 X-Original-Date: Tue, 23 Apr 2019 08:50:21 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:07:25 -0000 On Tue, Apr 23, 2019 at 6:47 AM Konstantin Belousov 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 > > 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