Al Viro <v...@zeniv.linux.org.uk> wrote:
>On Thu, Aug 06, 2020 at 12:59:16PM +0100, Al Viro wrote:
>> On Thu, Aug 06, 2020 at 07:53:16PM +0800, linmiaohe wrote:
>> > From: Miaohe Lin <linmia...@huawei.com>
>> >
>> > We should fput() file iff FDPUT_FPUT is set. So we should set
>> > fput_needed accordingly.
>> >
>> > Fixes: 00e188ef6a7e ("sockfd_lookup_light(): switch to fdget^W^Waway
>> > from fget_light")
>>
>> Explain, please. We are getting it from fdget(); what else can we get in
>> flags there?
>
>FWIW, struct fd ->flags may have two bits set: FDPUT_FPUT and FDPUT_POS_UNLOCK.
>The latter is set only by __fdget_pos() and its callers, and that only for
>regular files and directories.
>
>Nevermind that sockfd_lookup_light() does *not* use ..._pos() family of
>primitives, even if it started to use e.g. fdget_pos() it *still* would not
>end up with anything other than FDPUT_FPUT to deal with on that path - it
>checks that what it got is a socket. Anything else is dropped right there,
>without leaving fput() to caller.
>
>So could you explain what exactly the bug is - if you are seeing some breakage
>and this patch fixes it, something odd is definitely going on and it would be
>nice to figure out what that something is.
I'am sorry, but I did not find something odd. I do this because this would make
code more clear and consistent. It's pure a clean up patch.
Maybe Fixes tag makes this looks like a bugfix.
Thanks for your reply and detailed explaination. :)
And sorry for my rookie mistake, I wasn't meant to make these as a patch set...
