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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 B9700C2BB1D for ; Tue, 14 Apr 2020 22:22:34 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6530020767 for ; Tue, 14 Apr 2020 22:22:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="pOCxwRST" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6530020767 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4920NS2qGtzDqy1 for ; Wed, 15 Apr 2020 08:22:32 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=pOCxwRST; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 491lxP5BkWzDqfp for ; Tue, 14 Apr 2020 23:01:45 +1000 (AEST) 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 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-Mailman-Approved-At: Wed, 15 Apr 2020 08:15:09 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Song Liu , linux-usb@vger.kernel.org, bpf@vger.kernel.org, "Rafael J. Wysocki" , David Airlie , Heiko Carstens , Alexei Starovoitov , dri-devel@lists.freedesktop.org, "J. Bruce Fields" , Joseph Qi , Hugh Dickins , Paul Mackerras , John Johansen , netdev@vger.kernel.org, ocfs2-devel@oss.oracle.com, Christoph Hellwig , Andrew Donnellan , Matthew Garrett , linux-efi@vger.kernel.org, Arnd Bergmann , Daniel Borkmann , Christian Borntraeger , linux-rdma@vger.kernel.org, Mark Fasheh , Anton Vorontsov , John Fastabend , James Morris , Ard Biesheuvel , Jason Gunthorpe , Doug Ledford , oprofile-list@lists.sf.net, Yonghong Song , Ian Kent , Andrii Nakryiko , Alexey Dobriyan , "Serge E. Hallyn" , Robert Richter , Thomas Zimmermann , Vasily Gorbik , Tony Luck , Kees Cook , "James E.J. Bottomley" , autofs@vger.kernel.org, Maarten Lankhorst , Mike Marciniszyn , Maxime Ripard , linux-fsdevel@vger.kernel.org, "Manoj N. Kumar" , Uma Krishnan , Jakub Kicinski , KP Singh , Trond Myklebust , "Matthew R. Ochs" , "David S. Miller" , Felipe Balbi , linux-nfs@vger.kernel.org, Iurii Zaikin , linux-scsi@vger.kernel.org, "Martin K. Petersen" , linux-mm@kvack.org, linux-s390@vger.kernel.org, Dennis Dalessandro , Miklos Szeredi , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Anna Schumaker , Luis Chamberlain , Chuck Lever , Jeremy Kerr , Daniel Vetter , Colin Cross , Frederic Barrat , Paolo Bonzini , Andrew Morton , Mike Kravetz , linuxppc-dev@lists.ozlabs.org, Martin KaFai Lau , Joel Becker , Alexander Viro Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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