[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7d3e7bf5-22e4-ab3d-798e-33d3657e1cf1@linuxfoundation.org>
Date: Fri, 8 May 2020 09:07:26 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Luis Chamberlain <mcgrof@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>
Cc: axboe@...nel.dk, zohar@...ux.vnet.ibm.com, keescook@...omium.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH 1/2] fs: avoid fdput() after failed fdget() in
ksys_sync_file_range()
On 5/7/20 8:21 PM, Luis Chamberlain wrote:
> On Fri, May 08, 2020 at 01:24:22AM +0100, Al Viro wrote:
>> 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...
>
> This makes it easier to read.
>
Yes it does. I will make the changes and send v2.
thanks,
-- Shuah
Powered by blists - more mailing lists