On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <[email protected]> wrote:
>
>> On Jan 26, 2016, at 18:30, Ilya Dryomov <[email protected]> wrote:
>>
>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>> <[email protected]> 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 <[email protected]>
>>>
>>> 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.
Thanks,
Ilya
