Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2090217ybl; Thu, 29 Aug 2019 03:27:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0Wgo+CDbMePxpt+hSVvjTnUBfxiGSFTsMd3+fYm0bas3G5Ah11ZDpo0GFGnBmC+1UlVw7 X-Received: by 2002:a63:5648:: with SMTP id g8mr7458762pgm.81.1567074451017; Thu, 29 Aug 2019 03:27:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567074451; cv=none; d=google.com; s=arc-20160816; b=IZcdF/7SAmw6UM3H3EeMOQP2+HYhTECdPYJUlUHyNAbmfcjcuc7wdWvHrdp+GgneJp Q9oImDRbuf8YmxQxWkiDnz63R6kIdQZ6+9feCrk35djORcVa2LIH4YHXtBu1SBXejTl7 9ANauA7PIZ03qN0YftWuWaQydNctY70zH5Tsy+9R18838wsKz/7pQxCZsVzUDsZ7EuOA 87TqwEf29WnPhfGFkZiX8yJwdllg5c4jGcfwMJf87JKbSLFghNUGVOkcfr/1VbZ+4y4n 7lRB4ESXhBPJXpTL8bYakC4RG4VZnZEapp+A1ZH5f35/DUu5LAy4yamiDwB7oZfuIcoZ LlSw== 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:dkim-signature; bh=uzKJKYZqh5cldXspEq4aviAtZz0ZMSP0fdY/FxrxRb8=; b=QuKLDuotENfncodT+6D35vfy6AfjWH1ASYBQ/lQmIbG7imzfY8c9IOg4IqLTD0H4Hy WttRbU8S2Ffy9qBRQTF+qBNyTBUQos47odTLVJJm3WjuailvqpUEv4eg6Xdt43i/lmK4 uykgVp+ymkC2rJwxoxtfY2GnRvTyXgRzuqAB69t92vJ+oa7Snxuyrl7DFGTOuqqnNkEi MrwgQI/5DVAaOlVLcnuZuSH/yJl6ozzxWdFnp9+5QwhtS8e2m2+Ew0Z58EOQ+WFW/tLq 0ZUddnDLtEH5hCdy5vzk3AyOcLhUg90Pntp8myuhX0l/EB0ppSavbKPlaIQ70e31VRea TfAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=pvLXSzik; 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 b36si1444128pla.403.2019.08.29.03.27.15; Thu, 29 Aug 2019 03:27:30 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=pvLXSzik; 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 S1727381AbfH2KYi (ORCPT + 99 others); Thu, 29 Aug 2019 06:24:38 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:55840 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726637AbfH2KYi (ORCPT ); Thu, 29 Aug 2019 06:24:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uzKJKYZqh5cldXspEq4aviAtZz0ZMSP0fdY/FxrxRb8=; b=pvLXSzikK4jCyckorJkttc/nk E0m9v2p9AQEptN/i/zCuaWhA9JEKbgpZZcHl/w2YReY2IjGzciU3M43LLVZLZL+wuaZXGsgZ37FY4 d3qeURL1WsVXbwNN8lYRTR398q3SBQLzAWCBIA2rzk4sSsbnQPCLUNyr5JVUyt5yXYxxV/Cjxzy+N nJDvZ16fAoVnoCHpt/1S6uDBh63+nOxa6Kv8j18kex/JOrbl5zkgMpcfdcLDTPYSewrdK0tXF4/SF ArtQBRVU0RsnX0bg8H4Y2DNilmS45BAJFRoVqKwJlqVgW4/DYDBIXaoRO7bqN9s0xgJCQhlldLI/n 9DJlZoDjA==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1i3HbO-00077V-LK; Thu, 29 Aug 2019 10:24:26 +0000 Date: Thu, 29 Aug 2019 03:24:26 -0700 From: Christoph Hellwig To: Gao Xiang Cc: Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , Pavel Machek , David Sterba , Amir Goldstein , Christoph Hellwig , "Darrick J . Wong" , Dave Chinner , Jaegeuk Kim , Jan Kara , Linus Torvalds , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, LKML , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei Subject: Re: [PATCH v6 05/24] erofs: add inode operations Message-ID: <20190829102426.GE20598@infradead.org> References: <20190802125347.166018-1-gaoxiang25@huawei.com> <20190802125347.166018-6-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190802125347.166018-6-gaoxiang25@huawei.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 02, 2019 at 08:53:28PM +0800, Gao Xiang wrote: > This adds core functions to get, read an inode. > It adds statx support as well. > > Signed-off-by: Gao Xiang > --- > fs/erofs/inode.c | 291 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 291 insertions(+) > create mode 100644 fs/erofs/inode.c > > diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c > new file mode 100644 > index 000000000000..b6ea997bc4ae > --- /dev/null > +++ b/fs/erofs/inode.c > @@ -0,0 +1,291 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * linux/fs/erofs/inode.c > + * > + * Copyright (C) 2017-2018 HUAWEI, Inc. > + * http://www.huawei.com/ > + * Created by Gao Xiang > + */ > +#include "internal.h" > + > +#include > + > +/* no locking */ > +static int read_inode(struct inode *inode, void *data) > +{ > + struct erofs_vnode *vi = EROFS_V(inode); > + struct erofs_inode_v1 *v1 = data; > + const unsigned int advise = le16_to_cpu(v1->i_advise); > + erofs_blk_t nblks = 0; > + > + vi->datamode = __inode_data_mapping(advise); What is the deal with these magic underscores here and various other similar helpers? > + /* fast symlink (following ext4) */ This actually originates in FFS. But it is so common that the comment seems a little pointless. > + if (S_ISLNK(inode->i_mode) && inode->i_size < PAGE_SIZE) { > + char *lnk = erofs_kmalloc(sbi, inode->i_size + 1, GFP_KERNEL); Please just use plain kmalloc everywhere and let the normal kernel error injection code take care of injeting any errors. > + /* inline symlink data shouldn't across page boundary as well */ ... should not cross .. > + if (unlikely(m_pofs + inode->i_size > PAGE_SIZE)) { > + DBG_BUGON(1); > + kfree(lnk); > + return -EIO; > + } > + > + /* get in-page inline data */ s/get/copy/, but the comment seems rather pointless. > + memcpy(lnk, data + m_pofs, inode->i_size); > + lnk[inode->i_size] = '\0'; > + > + inode->i_link = lnk; > + set_inode_fast_symlink(inode); Please just set the ops directly instead of obsfucating that in a single caller, single line inline function. And please set it instead of the normal symlink iops in the same place where you also set those.:w > + err = read_inode(inode, data + ofs); > + if (!err) { if (err) goto out_unlock; .. and save one level of indentation. > + if (is_inode_layout_compression(inode)) { The name of this helper is a little odd. But I think just opencoding it seems generally cleaner anyway. > + err = -ENOTSUPP; > + goto out_unlock; > + } > + > + inode->i_mapping->a_ops = &erofs_raw_access_aops; > + > + /* fill last page if inline data is available */ > + err = fill_inline_data(inode, data, ofs); Well, I think you should move the is_inode_flat_inline and (S_ISLNK(inode->i_mode) && inode->i_size < PAGE_SIZE) checks from that helper here, as otherwise you make everyone wonder why you'd always fill out the inline data. > +static inline struct inode *erofs_iget_locked(struct super_block *sb, > + erofs_nid_t nid) > +{ > + const unsigned long hashval = erofs_inode_hash(nid); > + > +#if BITS_PER_LONG >= 64 > + /* it is safe to use iget_locked for >= 64-bit platform */ > + return iget_locked(sb, hashval); > +#else > + return iget5_locked(sb, hashval, erofs_ilookup_test_actor, > + erofs_iget_set_actor, &nid); > +#endif Just use the slightly more complicated 32-bit version everywhere so that you have a single actually tested code path. And then remove this helper.