Re: [PATCH 1/2] fs: avoid fdput() after failed fdget() in ksys_sync_file_range()

From: Al Viro <viro@zeniv.linux.org.uk>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: axboe@kernel.dk, zohar@linux.vnet.ibm.com, mcgrof@kernel.org,
	keescook@chromium.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: avoid fdput() after failed fdget() in ksys_sync_file_range()
Date: Fri, 8 May 2020 01:24:22 +0100	[thread overview]
Message-ID: <20200508002422.GL23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200508000509.GK23230@ZenIV.linux.org.uk>

On Fri, May 08, 2020 at 01:05:09AM +0100, Al Viro wrote:
> On Thu, May 07, 2020 at 05:57:09PM -0600, Shuah Khan wrote:
> > Fix ksys_sync_file_range() to avoid fdput() after a failed fdget().
> > fdput() doesn't do fput() on this file since FDPUT_FPUT isn't set
> > in fd.flags. Fix it anyway since failed fdget() doesn't require
> > a fdput().
> > 
> > This was introdcued in a commit to add sync_file_range() helper.
> 
> Er...  What's the point microoptimizing the slow path here?

PS: I'm not saying the patch is incorrect, but Fixes: is IMO over the
top.  And looking at that thing,
{
        struct fd f = fdget(fd);
        int ret;

	if (unlikely(!f.file))
		return -EBADF;

	ret = sync_file_range(f.file, offset, nbytes, flags);
        fdput(f);
        return ret;
}

might be cleaner, but that's a matter of taste...