[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <25A36812-97DA-46D7-BE1A-A8C15C2A29AC@redhat.com>
Date: Tue, 26 Jan 2016 19:54:32 +0800
From: "Yan, Zheng" <zyan@...hat.com>
To: Ilya Dryomov <idryomov@...il.com>
Cc: Dan Carpenter <dan.carpenter@...cle.com>,
Sage Weil <sage@...hat.com>,
Ceph Development <ceph-devel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: [patch] ceph: checking for IS_ERR instead of NULL
> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@...il.com> wrote:
>
> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@...hat.com> wrote:
>>
>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@...il.com> wrote:
>>>
>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>> <dan.carpenter@...cle.com> wrote:
>>>> ceph_osdc_alloc_request() returns NULL on error, it never returns error
>>>> pointers.
>>>>
>>>> Fixes: 5be0389dac66 ('ceph: re-send AIO write request when getting -EOLDSNAP error')
>>>> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
>>>>
>>>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>>>> index d37efdd..a52cf9b 100644
>>>> --- a/fs/ceph/file.c
>>>> +++ b/fs/ceph/file.c
>>>> @@ -698,8 +698,8 @@ static void ceph_aio_retry_work(struct work_struct *work)
>>>>
>>>> req = ceph_osdc_alloc_request(orig_req->r_osdc, snapc, 2,
>>>> false, GFP_NOFS);
>>>> - if (IS_ERR(req)) {
>>>> - ret = PTR_ERR(req);
>>>> + if (!req) {
>>>> + ret = -ENOMEM;
>>>> req = orig_req;
>>>> goto out;
>>>> }
>>>
>>> Applied, thanks Dan.
>>>
>>> Zheng, I have an related concern: where do you put snapc (refcount is
>>> bumped a few lines above) if ceph_osdc_alloc_request() fails? It looks
>>> like it's leaked to me.
>>>
>>> The BUG_ON(ret == -EOLDSNAPC) also seems a bit bogus, given that ret is
>>> either -ENOMEM or ceph_osdc_start_request() retval.
>>
>> ceph_aio_complete_req treats -EOLDSNAP distinguishingly. Purpose of this BUG_ON is detect potential infinite loop.
>
> Did you miss the part about the snap context?
>
> I get the purpose of -EOLDSNAPC assert in ceph_direct_read_write(),
> where you can actually get it from ceph_osdc_wait_request() - it's
> a server-side error code. Asserting it in ceph_aio_retry_work(), in
> which only client helpers are called and the only two possible error
> codes are -ENOMEM and -EIO doesn't make much sense to me.
>
Yeah, removing that BUG_ON is completely OK.
Regards,
Yan, Zheng
> Thanks,
>
> Ilya
Powered by blists - more mailing lists