From owner-freebsd-arch@freebsd.org Thu Feb 14 17:51:14 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 CB31714DBC1E for ; Thu, 14 Feb 2019 17:51:14 +0000 (UTC) (envelope-from cse.cem@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 40E5883D2F for ; Thu, 14 Feb 2019 17:51:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id F26DB14DBC1D; Thu, 14 Feb 2019 17:51:13 +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 B27FD14DBC1C for ; Thu, 14 Feb 2019 17:51:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAC2083D28 for ; Thu, 14 Feb 2019 17:51:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f169.google.com with SMTP id z9so15299840itc.4 for ; Thu, 14 Feb 2019 09:51:12 -0800 (PST) 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:reply-to :from:date:message-id:subject:to:cc; bh=JyLb04kHvZvjdqzezoH3NL6czs51H+m04qlPpWoc8Tk=; b=aMcEarQEtu3CRFJQaH1duwWwp830SSWqfPgdOQDKmj398XYl5lezm3KymIQCt51qbA OHgZhpf/Kg5oO01SAQnVOWCERrjrdAYEG7BbiI0lB7od89YBuErAE7L8Pgun453tNBs4 IP7ymuPlDXdefPMCw529Suk/QfA2WOUzosEoWpv/CpQ9ShAv0bg59akWfxen8REuVCcf SBLRSn4kVsrBdKl1ZHUK32pAV8nXKWeQWYp+znjuNsZsPMdIdH23ksEJ2l7yHAy+r1Uf pNwJafv0byOKcs5u4k+b9Rf9cwn8BxFDShC2GFwTrvKz1TcoNpF874e5vIRiQPrM5oLo XHXQ== X-Gm-Message-State: AHQUAuaeG9n1y1Ls28IU9/W3oBAbTxFJ3w+siLIv5e0L0/rQC9WNQVw8 7LVJafqO6QE54gvs8ZYhQzbRNILk X-Google-Smtp-Source: AHgI3IZEu5G7sY214o186w4MxLkJytZQa+NOSFfEcdXxXmiqXGeipJ46IkFOGoB4dOuDFzwha39iLg== X-Received: by 2002:a6b:c402:: with SMTP id y2mr3317795ioa.77.1550166666159; Thu, 14 Feb 2019 09:51:06 -0800 (PST) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id n16sm1182220iom.58.2019.02.14.09.51.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 09:51:06 -0800 (PST) Received: by mail-it1-f170.google.com with SMTP id l66so6339568itg.3 for ; Thu, 14 Feb 2019 09:51:05 -0800 (PST) X-Received: by 2002:a02:9f86:: with SMTP id a6mr2739915jam.87.1550166665828; Thu, 14 Feb 2019 09:51:05 -0800 (PST) MIME-Version: 1.0 References: <20190212071929.GB24863@kib.kiev.ua> In-Reply-To: <20190212071929.GB24863@kib.kiev.ua> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Thu, 14 Feb 2019 09:50:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: What to do about VOP_INACTIVE? To: Konstantin Belousov Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: AAC2083D28 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.82)[-0.824,0]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[169.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[169.166.85.209.rep.mailspike.net : 127.0.0.17]; IP_SCORE(-2.96)[ip: (-8.95), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.98), country: US(-0.07)] 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 17:51:15 -0000 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. > 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