From owner-freebsd-arch@freebsd.org Thu Feb 14 18:35:35 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8534914DD57F for ; Thu, 14 Feb 2019 18:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 08D1086002 for ; Thu, 14 Feb 2019 18:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BB7A114DD57E; Thu, 14 Feb 2019 18:35:34 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 965BA14DD57D for ; Thu, 14 Feb 2019 18:35:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE9FF86000; Thu, 14 Feb 2019 18:35:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1EIZPaM011795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 20:35:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1EIZPaM011795 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1EIZPbX011793; Thu, 14 Feb 2019 20:35:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2019 20:35:25 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: "freebsd-arch@freebsd.org" Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <20190214183525.GK24863@kib.kiev.ua> References: <20190212071929.GB24863@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:35:35 -0000 On Thu, Feb 14, 2019 at 09:50:55AM -0800, Conrad Meyer wrote: > Hi Konstantin, > > On Mon, Feb 11, 2019 at 11:19 PM Konstantin Belousov > wrote: > > Our close(2) always removes the file descriptor from the process table, > > regardless of the error returned, except for the EBADF situation. > > Due to this, if some filesystem like FUSE have to stop executing its > > VOP_INACTIVE due to signal, it does not change anything for the caller. > > Sure. Does it violate any contract that the kernel relies upon? For > example, vgonel() will issue a VOP_INACTIVE() followed by > VOP_RECLAIM(); I guess this means filesystems with interruptible > INACTIVE cannot rely upon RECLAIMed vnodes being inactivated first. VFS does not guarantee that VOP_INACTIVE is always called when the use count reaches zero. Look e.g. at vputx() where we only call the inactive method when we were able to upgrade to exclusive lock, and look at vget() where we only call it when we locked exclusive. In other words, the reclaim method of a filesystem must be prepared to do the work, it is typically done by calling internal inactivation function from VOP_RECLAIM. > > > On the other hand, allowing unbound interruptible sleeps in the > > implementation of inactive or reclaim is very dangerous practice, since > > executing the VOPs on the vnode reclamation from VFS daemons would stop > > free vnode supply to the system, effectively blocking it. In less > > dangerous situation, it would block unmount. > > This is a good concern. Even bounding sleep to some plausible time > per individual vnode would drastically restrict VFS daemons' ability > to process many vnodes in a timely fashion. And eliminating sleeps or > bounding them to very short times may be undesirable the majority of > the time (userspace close). > > I don't know what the best way to fix this is. We could plumb a flag > argument down to INACTIVE and RECLAIM methods. On the other hand, we > already have the 'td' argument. Maybe that is a sufficient for VOP > methods to determine whether the caller is userspace or a kernel > daemon. > > Either way, vinactive() and callers will not make any use of an EAGAIN > signal, so why have the 'int' return type? It is misleading. > > > I do not think that efforts to change VOP_INACTIVE() return type to void > > are worth the time. > > It's trivial; I'm happy to do it. > > Thanks, > Conrad