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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81982C6FA82 for ; Wed, 21 Sep 2022 15:08:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbiIUPIF (ORCPT ); Wed, 21 Sep 2022 11:08:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbiIUPIE (ORCPT ); Wed, 21 Sep 2022 11:08:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B2747754D for ; Wed, 21 Sep 2022 08:08:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 11EC2B82509 for ; Wed, 21 Sep 2022 15:08:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7135C433D6; Wed, 21 Sep 2022 15:07:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663772880; bh=g6qJp0RW67KdIQdwo9pb4hUX+aXyZQEqiebt0VzSv9k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VdPyup6Ww6sryRy3y9HmQqnF3m+IDuwCBIkB7Km0sgC1wL967Nc3MYOD6EBt/KT5w hGODZEiUcjXYhZn+vN4/UUiI9J13P+7mYCNodv+d7AHg9T0Gqrr2y3Cz17XfYJUFGs iVG1C+NQCibm5Od5tj7af3jpN/AlCjJG/x6Bhiw9KlW1HBgJmO14JymedRVnIIHpCn UFceB2UgxgEf/4LiVAqcCysumDt2m+JMd+DQxCV2Fg/A+k5BROauHFdeH4bqDicYHf BzZKqK5xdy1yuMt98MQHgrurdychPH3TxLkv8rYHBbApfaScD+lbURJCZKnB6omSOp v458DfBydrFkg== Date: Wed, 21 Sep 2022 17:07:50 +0200 From: Christian Brauner To: Miklos Szeredi Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, Al Viro , Amir Goldstein , David Howells , Yu-li Lin , Chirantan Ekbote Subject: Re: [PATCH v3 8/9] vfs: open inside ->tmpfile() Message-ID: <20220921150750.grruzm3copwproyu@wittgenstein> References: <20220920193632.2215598-1-mszeredi@redhat.com> <20220920193632.2215598-9-mszeredi@redhat.com> <20220921090820.woijqimkphaf3qll@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Sep 21, 2022 at 04:58:38PM +0200, Miklos Szeredi wrote: > On Wed, 21 Sept 2022 at 11:08, Christian Brauner wrote: > > > > On Tue, Sep 20, 2022 at 09:36:31PM +0200, Miklos Szeredi wrote: > > > This is in preparation for adding tmpfile support to fuse, which requires > > > that the tmpfile creation and opening are done as a single operation. > > > > > > Replace the 'struct dentry *' argument of i_op->tmpfile with > > > 'struct file *'. > > > > > > Call finish_open_simple() as the last thing in ->tmpfile() instances (may > > > be omitted in the error case). > > > > > > Change d_tmpfile() argument to 'struct file *' as well to make callers more > > > readable. > > > > > > Signed-off-by: Miklos Szeredi > > > --- > > > > Seems fine to me. Fwiw, it feels like all the file->f_path.dentry derefs > > could be wrapped in a helper similar to file_inode(). I know we have > > file_dentry() but that calls d_real() so not sure if that'll be correct > > for all updated callers, > > I don't think file_dentry() should be used for this. > > file_dentry() is basically a hack for overlayfs's "fake path" thing. > It should only be used where strictly necessary. At one point it > would be good to look again at cleaning this mess up. Yeah, that's what I was getting at. The file_dentry() helper would ideally just be as simple as file_inode() and then we'd have file_dentry_real() for the stacking filesystem scenarios.