Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Aug 2023 04:18:38 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Mateusz Guzik <mjguzik@gmail.com>
Cc:     viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org, oleg@redhat.com
Subject: Re: [PATCH] fs: use __fput_sync in close(2)
Message-ID: <ZNBijjmst12/V87J@casper.infradead.org>
References: <20230806230627.1394689-1-mjguzik@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230806230627.1394689-1-mjguzik@gmail.com>
Precedence: bulk

On Mon, Aug 07, 2023 at 01:06:27AM +0200, Mateusz Guzik wrote:
> With the assumption this is not going to work, I wrote my own patch
> which adds close_fd_sync() and filp_close_sync().  They are shipped as
> dedicated func entry points, but perhaps inlines which internally add a
> flag to to the underlying routine would be preferred?

Yes, I think static inlines would be better here.  

> Also adding __ in
> front would be in line with __fput_sync, but having __filp_close_sync
> call  __filp_close looks weird to me.

I'd handle this as ...

int file_close_sync(struct file *, fl_owner_t, bool sync);
static inline filp_close(struct file *file, fl_owner_t owner)
{
	return file_close_sync(file, owner, false);
}