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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 D3989C2BBC7 for ; Tue, 14 Apr 2020 13:01:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 977472075E for ; Tue, 14 Apr 2020 13:01:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="pOCxwRST" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 977472075E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 416C48E0003; Tue, 14 Apr 2020 09:01:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A00F8E0001; Tue, 14 Apr 2020 09:01:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28E388E0003; Tue, 14 Apr 2020 09:01:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id 0DB028E0001 for ; Tue, 14 Apr 2020 09:01:45 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C0215180AD807 for ; Tue, 14 Apr 2020 13:01:44 +0000 (UTC) X-FDA: 76706472528.25.comb86_2c4941bb9bf28 X-HE-Tag: comb86_2c4941bb9bf28 X-Filterd-Recvd-Size: 5845 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 13:01:44 +0000 (UTC) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 E704E20732; Tue, 14 Apr 2020 13:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586869303; bh=pWPiuEMg4P2H6WWtKoeEIrJA7EIxTZWcj4PZDt4NV3A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pOCxwRSTLKG+fKpoNN6pL7bEaN07jAmFr2DuV0C9RfMmBlnWAv1JOM6YaFZT6nGbN ondepi//P7WD886QVYVo/H59B351/kYJKvtSpuSM2jwd5MW3QWne+H2FTR56zMYOCD F4NR2z3OGSVjhXk6eqQkeYr86KdJjXN3jC1vRArk= Date: Tue, 14 Apr 2020 15:01:40 +0200 From: Greg Kroah-Hartman To: Emanuele Giuseppe Esposito Cc: linux-nfs@vger.kernel.org, Paolo Bonzini , Jeremy Kerr , Arnd Bergmann , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Dennis Dalessandro , Mike Marciniszyn , Doug Ledford , Jason Gunthorpe , Frederic Barrat , Andrew Donnellan , Robert Richter , "Manoj N. Kumar" , "Matthew R. Ochs" , Uma Krishnan , "James E.J. Bottomley" , "Martin K. Petersen" , Felipe Balbi , Alexander Viro , Ian Kent , Joel Becker , Christoph Hellwig , "Rafael J. Wysocki" , Matthew Garrett , Ard Biesheuvel , Miklos Szeredi , Mike Kravetz , Mark Fasheh , Joseph Qi , Alexey Dobriyan , Luis Chamberlain , Kees Cook , Iurii Zaikin , Anton Vorontsov , Colin Cross , Tony Luck , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Hugh Dickins , Andrew Morton , "J. Bruce Fields" , Chuck Lever , Trond Myklebust , Anna Schumaker , "David S. Miller" , Jakub Kicinski , James Morris , "Serge E. Hallyn" , John Johansen , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, oprofile-list@lists.sf.net, linux-scsi@vger.kernel.org, linux-usb@vger.kernel.org, linux-fsdevel@vger.kernel.org, autofs@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, ocfs2-devel@oss.oracle.com, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH 4/8] fs: introduce simple_new_inode Message-ID: <20200414130140.GD720679@kroah.com> References: <20200414124304.4470-1-eesposit@redhat.com> <20200414124304.4470-5-eesposit@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200414124304.4470-5-eesposit@redhat.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 14, 2020 at 02:42:58PM +0200, Emanuele Giuseppe Esposito wrote: > It is a common special case for new_inode to initialize the > time to the current time and the inode to get_next_ino(). > Introduce a core function that does it and use it throughout > Linux. Shouldn't this just be called new_inode_current_time()? How is anyone going to remember what simple_new_inode() does to the inode structure? > --- a/fs/libfs.c > +++ b/fs/libfs.c > @@ -595,6 +595,18 @@ int simple_write_end(struct file *file, struct address_space *mapping, > } > EXPORT_SYMBOL(simple_write_end); > > +struct inode *simple_new_inode(struct super_block *sb) > +{ > + struct inode *inode = new_inode(sb); > + if (inode) { > + inode->i_ino = get_next_ino(); > + inode->i_atime = inode->i_mtime = > + inode->i_ctime = current_time(inode); > + } > + return inode; > +} > +EXPORT_SYMBOL(simple_new_inode); No kernel doc explaining that get_next_ino() is called already? Please document new global functions like this so we have a chance to know how to use them. Also, it is almost always easier to introduce a common function, get it merged, and _THEN_ send out cleanup functions to all of the different subsystems to convert over to it. Yes, it takes longer, but it makes it possible to do this in a way that can be reviewed properly, unlike this patch series :( thanks, greg k-h