Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4334996imm; Mon, 11 Jun 2018 10:32:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK8FQqbHjTjuZSCUFScKQHY8nuAekZbn/Nqwiz/gT616tyUEbpGRkqwz2eC5FFslBncUPB4 X-Received: by 2002:a63:6dce:: with SMTP id i197-v6mr73489pgc.215.1528738331542; Mon, 11 Jun 2018 10:32:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528738331; cv=none; d=google.com; s=arc-20160816; b=zXF7NdnnuGYisMwAOhj+4iPd2ByL/z1CS/nAp7TdHggUN9Lv0f7LLLpIKgVcg9GpG0 O6NP8lav/rWuqGCOoFn4rhG2PuYR38ZuI0m/Nl463fsi781hMzaZl6hrAxl6oB+EjS2X cc07X5sbZLCCUdOoFTxrCeReNuasGvF9nYMaqyn2RDBaBwwheh6MCR5NtdD0l5Av5fyr wOEXwah/lidLGoN2noRvyDhBRhbJTvsYDE5AUrQkBpVGKXhXvAML9W/WHctk9QIjsSyK SR0foos+lbuApRWL450WutjfDGQFHwGTRllXMe8j61eF44SHurmRp/T6TeyE4heN4whe 5X8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zcwq3ya6S/2qQxoSbYZ3J6JE9wqPEV4FdcuIWIXXQ1s=; b=fFk9Hc8YDCnAqxX6tKgMcfByDzLKiICwHuCoGQgm2qRJKstICI40y2dzmDn10awyFP vXkc2Zhr0vljus5U5c/wR+ep4LBcEnzCinkMIdsA9cB4MxUBJn1/dbKQYzAd1E+VJFRu dpjA6sEX5EH4LBf7VXFWEfxSv9h+OBu/owhyRp9Ym7GVdFZ79ABhEMMhHHX6AelOXVuO tJ1NoDW5SpLsTuNwSyZStvs6tiSYTuL9fnb1LZE6mG1MrPgD5DhcJEbm9bUxzhgflTr0 ZXOE67mfSVo1jE/tD27Ix0CUuN2P1JOTVFrJ0SsFyat4mqf/QMTAq6ErDResxoEvQgFO VmxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v39-v6si17148549pgn.510.2018.06.11.10.31.27; Mon, 11 Jun 2018 10:32:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933763AbeFKQn7 (ORCPT + 99 others); Mon, 11 Jun 2018 12:43:59 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:59220 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933508AbeFKQn5 (ORCPT ); Mon, 11 Jun 2018 12:43:57 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1fSPv9-0000xY-MW; Mon, 11 Jun 2018 16:43:55 +0000 Date: Mon, 11 Jun 2018 17:43:55 +0100 From: Al Viro To: Miklos Szeredi Cc: Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/11] vfs: factor out inode_insert5() Message-ID: <20180611164355.GV30522@ZenIV.linux.org.uk> References: <20180529144143.16378-1-mszeredi@redhat.com> <20180529144143.16378-10-mszeredi@redhat.com> <20180610054902.GQ30522@ZenIV.linux.org.uk> <20180610060159.GS30522@ZenIV.linux.org.uk> <20180611113230.GI23785@veci.piliscsaba.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180611113230.GI23785@veci.piliscsaba.redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 11, 2018 at 01:32:30PM +0200, Miklos Szeredi wrote: > Incremental follows. I think it's cleaner to initialize i_state and i_sb_list > up front (hence the use of new_inode()), but could just as well add to sb list > afterwards. > --- > diff --git a/fs/inode.c b/fs/inode.c > index 0df41bb77e0f..03c0d7c1296f 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -1098,8 +1098,10 @@ struct inode *iget5_locked(struct super_block *sb, unsigned long hashval, > > if (new) { > inode = inode_insert5(new, hashval, test, set, data); > - if (unlikely(inode != new)) > - iput(new); > + if (unlikely(inode != new)) { > + inode_sb_list_del(inode); > + destroy_inode(new); > + } The thing is, until you put it into the list, it's invisible to everyone other than iget5_locked() - no references in any shared data structures. Which outweighs the "it's somewhat irregular in not being on the list" considerably, as far as the complexity of analysis goes, especially since there are inodes that never get on that list and it's not something exotic - all sockets and pipes are that way, for starters. So IMO that should be dealt with in inode_insert5().