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=-2.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,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 0F119C10DAA for ; Wed, 9 Sep 2020 18:49:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C1A6B20C09 for ; Wed, 9 Sep 2020 18:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599677356; bh=0Hc0A2DHIpQxSXAUP1fYSrqZvdF79n71IkCFeuZVvus=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Bply5Nmnfa74x3wnntVqT4jIABNdfoSbN/oP9D504h+A0kDeyFGUXj3E1W+XPD3g9 4Me73znti126Ub3OzUB//IDV8ktVcIyQ0EITTs7MJB0+ePKv8PZqw29xQ7zLhekCAC wySbILLfRIZnlP9xjby+9qXlvD8LU+cpesuWU9aw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726414AbgIIStP (ORCPT ); Wed, 9 Sep 2020 14:49:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:43414 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725826AbgIIStO (ORCPT ); Wed, 9 Sep 2020 14:49:14 -0400 Received: from gmail.com (unknown [104.132.1.76]) (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 830AD2080C; Wed, 9 Sep 2020 18:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599677353; bh=0Hc0A2DHIpQxSXAUP1fYSrqZvdF79n71IkCFeuZVvus=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EYmVpe3PMtGnon7JXzpdciqTBAHxlDimISoc/VVCqmCj3Pl9WGnQoKknxx4SFwukt Lb/0BAGFm6JZ3RamYzCabZuwAH/xkKymqiYAO2xVVqKUJiWggL8sYvTQiWrWWEocq7 qNFpVoqAn78eXnfCgbSPkyO5RyFZ4jArvDUi78Z4= Date: Wed, 9 Sep 2020 11:49:12 -0700 From: Eric Biggers To: Jeff Layton Cc: ceph-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-fscrypt@vger.kernel.org, Al Viro Subject: Re: [RFC PATCH v2 01/18] vfs: export new_inode_pseudo Message-ID: <20200909184912.GA425889@gmail.com> References: <20200904160537.76663-1-jlayton@kernel.org> <20200904160537.76663-2-jlayton@kernel.org> <20200908033819.GD68127@sol.localdomain> <42e2de297552a8642bfe21ab082e490678b5be38.camel@kernel.org> <20200908223125.GA3760467@gmail.com> <6cfe023df5cf6c50d6197bb7c71b3fa6a51bf555.camel@kernel.org> <20200909161242.GA828@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org [+Cc Al] On Wed, Sep 09, 2020 at 12:51:02PM -0400, Jeff Layton wrote: > > > No, more like: > > > > > > Syscall Workqueue > > > ------------------------------------------------------------------------------ > > > 1. allocate an inode > > > 2. determine we can do an async create > > > and allocate an inode number for it > > > 3. hash the inode (must set I_CREATING > > > if we allocated with new_inode()) > > > 4. issue the call to the MDS > > > 5. finish filling out the inode() > > > 6. MDS reply comes in, and workqueue thread > > > looks up new inode (-ESTALE) > > > 7. unlock_new_inode() > > > > > > > > > Because 6 happens before 7 in this case, we get an ESTALE on that > > > lookup. > > > > How is ESTALE at (6) possible? (3) will set I_NEW on the inode when inserting > > it into the inode hash table. Then (6) will wait for I_NEW to be cleared before > > returning the inode. (7) will clear I_NEW and I_CREATING together. > > > > Long call chain, but: > > ceph_fill_trace > ceph_get_inode > iget5_locked > ilookup5(..._nowait, etc) > find_inode_fast > > > ...and find_inode_fast does: > > if (unlikely(inode->i_state & I_CREATING)) { > spin_unlock(&inode->i_lock); > return ERR_PTR(-ESTALE); > } Why does ilookup5() not wait for I_NEW to be cleared if the inode has I_NEW|I_CREATING, but it does wait for I_NEW to be cleared if I_NEW is set its own? That seems like a bug. - Eric