From owner-freebsd-arch@freebsd.org Tue Feb 12 01:33:43 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 0413614EC823 for ; Tue, 12 Feb 2019 01:33:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) 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 6C4A094CE0 for ; Tue, 12 Feb 2019 01:33:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 2B11314EC81A; Tue, 12 Feb 2019 01:33:42 +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 E498B14EC819 for ; Tue, 12 Feb 2019 01:33:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660085.outbound.protection.outlook.com [40.107.66.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC8494CDE; Tue, 12 Feb 2019 01:33:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM (52.132.89.15) by QB1PR01MB3314.CANPRD01.PROD.OUTLOOK.COM (52.132.86.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Tue, 12 Feb 2019 01:33:40 +0000 Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c]) by QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 01:33:40 +0000 From: Rick Macklem To: "freebsd-arch@freebsd.org" , "cem@freebsd.org" Subject: Re: What to do about VOP_INACTIVE? Thread-Topic: What to do about VOP_INACTIVE? Thread-Index: AQHUwm02MzmT3Pcfhk2kEOAgv/qJlaXbXsEV Date: Tue, 12 Feb 2019 01:33:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; QB1PR01MB3314; 6:Bvc8C7s1N9XEBcFpNkkhHAGuC8MNWNaQrfyh0OmgTOMFvtg2llUDDz98/H8hTzU0+U6AznBYTzHBhLnf4ME6zo1+e3cvvAtiCTaxvEUvwzlBpVt+DKha1jaQy5WUZ6Ym2RgGWGwu4kzlthzM9wgCH32lnrCKTefIWgWy0UAjZDLsAJVG+eEvA4lPMUz8KHHNBLSpG6V0qwl2JsxAWGTfOSatbeyB2UGvijiu7PH2pwxyKi4gXxnulK5ci2TP+fAOjhexRs5g75QfOS988tOxfjuyI94uXm/iTslUURiKeGdPAmzBv1KNhROrej05d8eVEluWGmvCuuQno+o364QxqeU9snENgIHOFF7qCGw5yM+f2Z8U4HUlNQttq9JPG/xx/oL64Imn5SC+0W/WzyV149OmRxzjh+MZMDopLDASEgpQOm2bDTnr67ySJ6ktADBZhQG5ri0+YBsLN9jWHw1x7g==; 5:lRmQggZUrq0V89i+KC1Dh5jIC/wMrx/63tlGPbriNSzg4nZ4nZtsIq7kTVzkQ1FFpv9zZLmGCNsqbB6D9v1IS/tY3R329rzZzN3XyuMWTwfxCjbzDT5gHYj5y9QzynGmqLzCgz6iMUaAgim7pGWe8LdGkwhS4oaNWk3J9uXq4u/WMnuWGMpUr6wfR87LkB5ProniX7l3xe+7bMVksUCuhA==; 7:93OqLvawxRIxZfOi7gYCBTEZnmDQarMrhqOQC/pv8pTUyzPC9d7Sx4sru71uyoIPZsfYFYCU5lK3jF9aT3HgE+MxmDeflfkw2bvsyPdlBjl7ZmfvW+79pRItNZYzWTQr2vknSYCJnJZJ7qQDrBhNNw== x-ms-office365-filtering-correlation-id: 2af6dbad-ed82-4aa3-aedb-08d6908a1dee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:QB1PR01MB3314; x-ms-traffictypediagnostic: QB1PR01MB3314: x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39860400002)(136003)(376002)(199004)(189003)(71200400001)(8676002)(81166006)(316002)(8936002)(7696005)(74316002)(186003)(229853002)(486006)(81156014)(74482002)(478600001)(68736007)(446003)(476003)(11346002)(110136005)(55016002)(9686003)(71190400001)(2906002)(14454004)(6436002)(105586002)(46003)(25786009)(102836004)(106356001)(14444005)(76176011)(256004)(6246003)(305945005)(2501003)(450100002)(97736004)(786003)(6506007)(33656002)(99286004)(53936002)(86362001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3314; H:QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fi9vmlPow5GMgTPIlgcI2NqROScFzGuUu3CMOdoxrG3uzR8sfqGvko+rVArJL3aoRGPQ8pQ81OY2qV1ErUUg8jmYS3x+tekupXi3uKiWuh00qYWJy4ri5DaxrZ7+A2oVRfA36i58TwXodOuBLBTcNj7NDcQHGS7nmkfXu04DrtNn2nU8PIbJ564euNe5tcYen+ZrLLodMQRGBFmHBpp0YDrJoWofhoe+vSq6U93Kt3EPVqH5Aft3FqVmdUW/LS6TGBiKdvCtPPJQyMgtAjVlYdUyBLx/jlYsPyuAeock8ZICwlO4zCePiV9P9SCVrYlaIamoMnhpiPkWn0IAO+d/d2U+X4pofkPBt7vF6NjKiEB/u6qTxJrMIfYFwu3wHurAiP7s/v69hOSIcywgIpT0Xt844pRRk+IXImVP7BVZgI0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 2af6dbad-ed82-4aa3-aedb-08d6908a1dee X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 01:33:40.0511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3314 X-Rspamd-Queue-Id: 6FC8494CDE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 12 Feb 2019 01:33:43 -0000 Conrad Meyer wrote: >The nominal return type of the VOP_INACTIVE vnode method is 'int', but >in practice any error returned is silently discarded. > >The only caller is vinactive(), which is also a void routine. >vinactive ignores the return value of VOP_INACTIVE(). (vinactive >tends to be called by other void routines, like vput(), so propagating >an error up the stack is non-trivial.) > >In practice, most filesystems in the kernel unconditionally return >zero for INACTIVE. The exceptions are: msdosfs, ext2fs, nandfs, and >(notably) ufs. > >The problem (as I see it) is that the return type makes it appear that >INACTIVE is allowed to fail, but it is not. One important >ramification of this is that interruptible sleeps in INACTIVE are >basically not permitted. > >This seems problematic because INACTIVE is invoked as part of >close(2), and we can potentially block that user process indefinitely >when the kernel filesystem is stalled on a network resource, or >something like a FUSE userspace filesystem (which can also access >network resources). > >Can we live with the current behavior (INACTIVE cannot fail)? In that >case, I think we should change its return type to void to match. > >Thoughts? Well Kostik is the expert, but my understanding is that a file system canno= t assume that VOP_INACTIVE() will actually be called for a vnode. As such, th= e file system needs to do anything it does in its VOP_INACTIVE() in its VOP_R= ECLAIM() as well, if it must be done before the vnode is reused. As such, a failed VOP_INACTIVE() doesn't seem to be meaningful, since it mi= ght not get called at all? Having said that, making sure file system implementors know the above seems more important than whether it returns int vs void. (ie. Returning 0 seems harmless to me and may be useful in the future. Sinc= e changing the VFS/VOP interface can only be done for major releases and req= uires all file systems to be changed, I leave it, but this is not a strong opini= on.) rick