> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@xxxxxxxxx> wrote:
>
> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
> <dan.carpenter@xxxxxxxxxx> 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@xxxxxxxxxx>
>>
>> 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.
Regards
Yan, Zheng
>
> Ilya
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
