* [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 9:24 ` Dan Carpenter
0 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2016-01-26 9:24 UTC (permalink / raw)
To: Yan, Zheng
Cc: Sage Weil, Ilya Dryomov, ceph-devel, linux-kernel, kernel-janitors
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@oracle.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;
}
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 9:24 ` Dan Carpenter
0 siblings, 0 replies; 14+ messages in thread
From: Dan Carpenter @ 2016-01-26 9:24 UTC (permalink / raw)
To: Yan, Zheng
Cc: Sage Weil, Ilya Dryomov, ceph-devel, linux-kernel, kernel-janitors
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@oracle.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;
}
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 9:24 ` Dan Carpenter
@ 2016-01-26 10:30 ` Ilya Dryomov
-1 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 10:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: Yan, Zheng, Sage Weil, Ceph Development, linux-kernel, kernel-janitors
On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
<dan.carpenter@oracle.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@oracle.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.
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 10:30 ` Ilya Dryomov
0 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 10:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: Yan, Zheng, Sage Weil, Ceph Development, linux-kernel, kernel-janitors
On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
<dan.carpenter@oracle.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@oracle.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.
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 10:30 ` Ilya Dryomov
@ 2016-01-26 11:16 ` Yan, Zheng
-1 siblings, 0 replies; 14+ messages in thread
From: Yan, Zheng @ 2016-01-26 11:16 UTC (permalink / raw)
To: Ilya Dryomov
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
> <dan.carpenter@oracle.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@oracle.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.
Regards
Yan, Zheng
>
> Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 11:16 ` Yan, Zheng
0 siblings, 0 replies; 14+ messages in thread
From: Yan, Zheng @ 2016-01-26 11:16 UTC (permalink / raw)
To: Ilya Dryomov
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
> <dan.carpenter@oracle.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@oracle.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.
Regards
Yan, Zheng
>
> Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 11:16 ` Yan, Zheng
@ 2016-01-26 11:40 ` Ilya Dryomov
-1 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 11:40 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>> <dan.carpenter@oracle.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@oracle.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.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 11:40 ` Ilya Dryomov
0 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 11:40 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>> <dan.carpenter@oracle.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@oracle.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.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 11:40 ` Ilya Dryomov
@ 2016-01-26 11:54 ` Yan, Zheng
-1 siblings, 0 replies; 14+ messages in thread
From: Yan, Zheng @ 2016-01-26 11:54 UTC (permalink / raw)
To: Ilya Dryomov
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>
>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>
>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>> <dan.carpenter@oracle.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@oracle.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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 11:54 ` Yan, Zheng
0 siblings, 0 replies; 14+ messages in thread
From: Yan, Zheng @ 2016-01-26 11:54 UTC (permalink / raw)
To: Ilya Dryomov
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>
>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>
>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>> <dan.carpenter@oracle.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@oracle.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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 11:54 ` Yan, Zheng
@ 2016-01-26 14:02 ` Ilya Dryomov
-1 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 14:02 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 12:54 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>
>>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>>> <dan.carpenter@oracle.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@oracle.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.
I still want to know where snapc is put ;)
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 14:02 ` Ilya Dryomov
0 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 14:02 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 12:54 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>
>>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>>> <dan.carpenter@oracle.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@oracle.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.
I still want to know where snapc is put ;)
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
2016-01-26 14:02 ` Ilya Dryomov
@ 2016-01-26 15:26 ` Ilya Dryomov
-1 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 15:26 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 3:51 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 22:02, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 12:54 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>
>>>> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>>>
>>>>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>>>>> <dan.carpenter@oracle.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@oracle.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.
>>
>> I still want to know where snapc is put ;)
>>
>
> you are right. I missed that
Great, you can remove that BUG_ON in the same commit then.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [patch] ceph: checking for IS_ERR instead of NULL
@ 2016-01-26 15:26 ` Ilya Dryomov
0 siblings, 0 replies; 14+ messages in thread
From: Ilya Dryomov @ 2016-01-26 15:26 UTC (permalink / raw)
To: Yan, Zheng
Cc: Dan Carpenter, Sage Weil, Ceph Development, linux-kernel,
kernel-janitors
On Tue, Jan 26, 2016 at 3:51 PM, Yan, Zheng <zyan@redhat.com> wrote:
>
>> On Jan 26, 2016, at 22:02, Ilya Dryomov <idryomov@gmail.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 12:54 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>
>>>> On Jan 26, 2016, at 19:40, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 26, 2016 at 12:16 PM, Yan, Zheng <zyan@redhat.com> wrote:
>>>>>
>>>>>> On Jan 26, 2016, at 18:30, Ilya Dryomov <idryomov@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 10:24 AM, Dan Carpenter
>>>>>> <dan.carpenter@oracle.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@oracle.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.
>>
>> I still want to know where snapc is put ;)
>>
>
> you are right. I missed that
Great, you can remove that BUG_ON in the same commit then.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-01-26 15:26 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-26 9:24 [patch] ceph: checking for IS_ERR instead of NULL Dan Carpenter
2016-01-26 9:24 ` Dan Carpenter
2016-01-26 10:30 ` Ilya Dryomov
2016-01-26 10:30 ` Ilya Dryomov
2016-01-26 11:16 ` Yan, Zheng
2016-01-26 11:16 ` Yan, Zheng
2016-01-26 11:40 ` Ilya Dryomov
2016-01-26 11:40 ` Ilya Dryomov
2016-01-26 11:54 ` Yan, Zheng
2016-01-26 11:54 ` Yan, Zheng
2016-01-26 14:02 ` Ilya Dryomov
2016-01-26 14:02 ` Ilya Dryomov
2016-01-26 15:26 ` Ilya Dryomov
2016-01-26 15:26 ` Ilya Dryomov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.