Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2079431ybl; Thu, 29 Aug 2019 03:17:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqxgzADbxAA7HKF8im3r2u24P6KXG7GyLBvEm98RdUEyK2NTJoI0sHtg85FaTnXpUgnVrChU X-Received: by 2002:a17:90a:be02:: with SMTP id a2mr9034768pjs.94.1567073840973; Thu, 29 Aug 2019 03:17:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567073840; cv=none; d=google.com; s=arc-20160816; b=MPk/dDf2v5L9zIxig6grPXcG42uOeb7ck8gXhULexBYyvljFJz8CJHJW9mB+II92aC aXe2VxmXamP41KZsTqSiFnXwBIK6gkROFjLm+LwM95IjSLGq5w1zfSWZf7yD2+C3kWYs dYWAK15K1e1mRjfCP3wXZaqVtRiwK2cb5O2oo7lc2xUBX3ip+XQrVrBdupEgTCmp9rvv aJVjixVmrMXhMv+Fk7QkMtsW6w9yTHXoxHrd9S6Lc5wCtQD8Yk13Np4xiQQRHN56McFI qzV8oQGQhqWp3qMpkwJ/Zz+wdPalOx9GMi56F/0A18nqOY3viEawGY5vrfB0yohSgDe4 m8pw== 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=+tvFhqmaMhEec6GVANstlSqfji2crmXW2QTn7NNJoKM=; b=WFSpd40ykHuIGjygPEzsoV4T0x/psJtxC5e/ucW1xhnqZxSeXj+KVEh/w75HogxcX6 VH7kzg8mui7eUaxq3OPBHgDFp6eYAtppxz1BquzjISKlnYCJCQldDshxgMLO8PIEdTxd u8gHMDNiYx9KElV02QjW7T5AOVb+Ag8nCe70kFlq389R79DGtc4SwaCqTnGbE3A4SgBN ux24kHaAjhXJLywbSL2rAqKt0dQiaytt70Ax52VJUkOk9lGCLS1wNfUvGQTmTLZ3Qxq2 lbml2BE7RVsm/H2JWCtwqF5yNU3sIvp9iEfrHb8nhwj+Cb8j5tVNA5Mvc2MOQUJ9tlf1 9ceQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=A8ByRWni; 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 d35si1541740pla.174.2019.08.29.03.17.04; Thu, 29 Aug 2019 03:17:20 -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=A8ByRWni; 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 S1727026AbfH2KQC (ORCPT + 99 others); Thu, 29 Aug 2019 06:16:02 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:52050 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726417AbfH2KQB (ORCPT ); Thu, 29 Aug 2019 06:16:01 -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=+tvFhqmaMhEec6GVANstlSqfji2crmXW2QTn7NNJoKM=; b=A8ByRWni1NBWV0UmmUIN/6rpi X3+y753F9ZqsThDJt7o7aQDx8POSMk6vACgG+5/80a1/+RSMhyYSRrmPLRpcTkxdB4r9jhP39z00m SNB0dmwp7a4mnINr37mvl1dEDK1Kpg50ghRaa+oGg1UZDZiYC/NOIUUu0XDWQCgHzf/0eIckqUF/1 9a6jhptLbC3I1vcXNZkpwv9AOY3c3Cp/r9EJxRPf72G+6RzZ1mF7BuKGpEZuA321ML2zD8nGEkrax VLgAfbmTT85kCCq9Gz0D6elE0GxuabOBX7ZlxpsnO0v9ywXu50/taO3Jf5w3NjCzs7tXNKdGet3j8 t6Mc6EgUA==; Received: from hch by bombadil.infradead.org with local (Exim 4.92 #3 (Red Hat Linux)) id 1i3HSz-0004ua-L6; Thu, 29 Aug 2019 10:15:45 +0000 Date: Thu, 29 Aug 2019 03:15:45 -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 03/24] erofs: add super block operations Message-ID: <20190829101545.GC20598@infradead.org> References: <20190802125347.166018-1-gaoxiang25@huawei.com> <20190802125347.166018-4-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190802125347.166018-4-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:26PM +0800, Gao Xiang wrote: > +static int __init erofs_init_inode_cache(void) > +{ > + erofs_inode_cachep = kmem_cache_create("erofs_inode", > + sizeof(struct erofs_vnode), 0, > + SLAB_RECLAIM_ACCOUNT, > + init_once); > + > + return erofs_inode_cachep ? 0 : -ENOMEM; Please just use normal if/else. Also having this function seems entirely pointless. > +static void erofs_exit_inode_cache(void) > +{ > + kmem_cache_destroy(erofs_inode_cachep); > +} Same for this one. > +static void free_inode(struct inode *inode) Please use an erofs_ prefix for all your functions. > +{ > + struct erofs_vnode *vi = EROFS_V(inode); Why is this called vnode instead of inode? That seems like a rather odd naming for a Linux file system. > + > + /* be careful RCU symlink path (see ext4_inode_info->i_data)! */ > + if (is_inode_fast_symlink(inode)) > + kfree(inode->i_link); is_inode_fast_symlink only shows up in a later patch. And really obsfucates the check here in the only caller as you can just do an unconditional kfree here - i_link will be NULL except for the case where you explicitly set it. Also this code is nothing like ext4, so the code seems a little confusing. > +static bool check_layout_compatibility(struct super_block *sb, > + struct erofs_super_block *layout) > +{ > + const unsigned int requirements = le32_to_cpu(layout->requirements); Why is the variable name for the on-disk subperblock layout? We usually still calls this something with sb in the name, e.g. dsb. for disk super block. > + EROFS_SB(sb)->requirements = requirements; > + > + /* check if current kernel meets all mandatory requirements */ > + if (requirements & (~EROFS_ALL_REQUIREMENTS)) { > + errln("unidentified requirements %x, please upgrade kernel version", > + requirements & ~EROFS_ALL_REQUIREMENTS); > + return false; > + } > + return true; Note that normally we call this features, but that doesn't really matter too much. > +static int superblock_read(struct super_block *sb) > +{ > + struct erofs_sb_info *sbi; > + struct buffer_head *bh; > + struct erofs_super_block *layout; > + unsigned int blkszbits; > + int ret; > + > + bh = sb_bread(sb, 0); Is there any good reasons to use buffer heads like this in new code vs directly using bios? > + > + sbi->blocks = le32_to_cpu(layout->blocks); > + sbi->meta_blkaddr = le32_to_cpu(layout->meta_blkaddr); > + sbi->islotbits = ffs(sizeof(struct erofs_inode_v1)) - 1; > + sbi->root_nid = le16_to_cpu(layout->root_nid); > + sbi->inos = le64_to_cpu(layout->inos); > + > + sbi->build_time = le64_to_cpu(layout->build_time); > + sbi->build_time_nsec = le32_to_cpu(layout->build_time_nsec); > + > + memcpy(&sb->s_uuid, layout->uuid, sizeof(layout->uuid)); > + memcpy(sbi->volume_name, layout->volume_name, > + sizeof(layout->volume_name)); s_uuid should preferably be a uuid_t (assuming it is a real BE uuid, if it is le it should be a guid_t). > +/* set up default EROFS parameters */ > +static void default_options(struct erofs_sb_info *sbi) > +{ > +} No need to add an empty function. > +static int erofs_fill_super(struct super_block *sb, void *data, int silent) > +{ > + struct inode *inode; > + struct erofs_sb_info *sbi; > + int err; > + > + infoln("fill_super, device -> %s", sb->s_id); > + infoln("options -> %s", (char *)data); That is some very verbose debug info. We usually don't add that and let people trace the function instead. Also you should probably implement the new mount API. new mount API. > +static void erofs_kill_sb(struct super_block *sb) > +{ > + struct erofs_sb_info *sbi; > + > + WARN_ON(sb->s_magic != EROFS_SUPER_MAGIC); > + infoln("unmounting for %s", sb->s_id); > + > + kill_block_super(sb); > + > + sbi = EROFS_SB(sb); > + if (!sbi) > + return; > + kfree(sbi); > + sb->s_fs_info = NULL; > +} Why is this needed? You can just free your sb privatte information in ->put_super and wire up kill_block_super as the ->kill_sb method directly.