From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 166D2C2D0A8 for ; Wed, 23 Sep 2020 11:19:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D1C17235FC for ; Wed, 23 Sep 2020 11:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600859944; bh=s7KZlKW570YDukapLdA9Wt51ipQNLRtgJmRlNjzRr80=; h=Subject:From:To:Cc:Date:In-Reply-To:References:List-ID:From; b=0VoQN4HEvTjN32L+QTgTGEAjML6HG7YOQD8IQe930sGa7K9Qu+IWCkCcf75U3tzLC 8hlDO6wUrbh4aOMG2cKwIqD4ZONSY6Zs7oWP/IYZaBZ48pUaqzijx1kvW+neROBpO4 r7GgkkanzNoAh60qMpyRf9kf3EGJlMOAu6b+ArEg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726682AbgIWLTE (ORCPT ); Wed, 23 Sep 2020 07:19:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:42072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726669AbgIWLTD (ORCPT ); Wed, 23 Sep 2020 07:19:03 -0400 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F29D8205F4; Wed, 23 Sep 2020 11:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600859943; bh=s7KZlKW570YDukapLdA9Wt51ipQNLRtgJmRlNjzRr80=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=S+bgCkwx13YIxJWEFMXiSyWmhfWKdJC1CPdvGdhKDixRF4orYecNrobhqHF0XAxs9 qAoxwCvTkuDjtgr0FIpF5dNacigxkE/5fY05jpDpel1z0hhCIUMSdK27Wy5/pSvudK p5DARIQ7kziOXE+l8wqWDTJtivGRuF36WueEbJB4= Message-ID: <6a630729889a962746a28d33e92bc7320ebfd02b.camel@kernel.org> Subject: Re: [RFC PATCH v3 01/16] vfs: export new_inode_pseudo From: Jeff Layton To: Al Viro Cc: ceph-devel@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Date: Wed, 23 Sep 2020 07:19:01 -0400 In-Reply-To: <20200923034134.GE3421308@ZenIV.linux.org.uk> References: <20200914191707.380444-1-jlayton@kernel.org> <20200914191707.380444-2-jlayton@kernel.org> <20200923034134.GE3421308@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org On Wed, 2020-09-23 at 04:41 +0100, Al Viro wrote: > On Mon, Sep 14, 2020 at 03:16:52PM -0400, Jeff Layton wrote: > > Ceph needs to be able to allocate inodes ahead of a create that might > > involve a fscrypt-encrypted inode. new_inode() almost fits the bill, > > but it puts the inode on the sb->s_inodes list and when we go to hash > > it, that might be done again. > > > > We could work around that by setting I_CREATING on the new inode, but > > that causes ilookup5 to return -ESTALE if something tries to find it > > before I_NEW is cleared. To work around all of this, just use > > new_inode_pseudo which doesn't add it to the list. > > Er... Why would you _not_ want -ESTALE in that situation? I'm hashing the new inode just before sending the create request to the MDS. When the reply comes in, the client then searches for that inode in the hash. If I_NEW has been cleared in the meantime -- no problem. If not, then we want the task handling the reply to wait until it is (and not get back an -ESTALE). -- Jeff Layton