Hi,
Static analysis with Coverity has detected a "dead-code" issue with the
following commit:
commit af9c1a44f8dee7a958e07977f24ba40e3c770987
Author: Jens Axboe <[email protected]>
Date: Thu Sep 24 13:32:18 2020 -0600
io_uring: process task work in io_uring_register()
The analysis is as follows:
9513 do {
9514 ret =
wait_for_completion_interruptible(&ctx->ref_comp);
cond_const: Condition ret, taking false branch. Now the value of ret is
equal to 0.
9515 if (!ret)
9516 break;
9517 if (io_run_task_work_sig() > 0)
9518 continue;
9519 } while (1);
9520
9521 mutex_lock(&ctx->uring_lock);
9522
const: At condition ret, the value of ret must be equal to 0.
dead_error_condition: The condition ret cannot be true.
9523 if (ret) {
Logically dead code (DEADCODE)
dead_error_begin: Execution cannot reach this statement:
9524 percpu_ref_resurrect(&ctx->refs);
9525 ret = -EINTR;
9526 goto out_quiesce;
9527 }
9528 }
9529
Colin
On Thu, Oct 8, 2020 at 8:24 PM Colin Ian King <[email protected]> wrote:
> Static analysis with Coverity has detected a "dead-code" issue with the
> following commit:
>
> commit af9c1a44f8dee7a958e07977f24ba40e3c770987
> Author: Jens Axboe <[email protected]>
> Date: Thu Sep 24 13:32:18 2020 -0600
>
> io_uring: process task work in io_uring_register()
>
> The analysis is as follows:
>
> 9513 do {
> 9514 ret =
> wait_for_completion_interruptible(&ctx->ref_comp);
>
> cond_const: Condition ret, taking false branch. Now the value of ret is
> equal to 0.
Does this mean Coverity is claiming that
wait_for_completion_interruptible() can't return non-zero values? If
so, can you figure out why Coverity thinks that? If that was true,
it'd sound like a core kernel bug, rather than a uring issue...
On Thu, Oct 8, 2020 at 9:13 PM Jann Horn <[email protected]> wrote:
>
> On Thu, Oct 8, 2020 at 8:24 PM Colin Ian King <[email protected]> wrote:
> > Static analysis with Coverity has detected a "dead-code" issue with the
> > following commit:
> >
> > commit af9c1a44f8dee7a958e07977f24ba40e3c770987
> > Author: Jens Axboe <[email protected]>
> > Date: Thu Sep 24 13:32:18 2020 -0600
> >
> > io_uring: process task work in io_uring_register()
> >
> > The analysis is as follows:
> >
> > 9513 do {
> > 9514 ret =
> > wait_for_completion_interruptible(&ctx->ref_comp);
> >
> > cond_const: Condition ret, taking false branch. Now the value of ret is
> > equal to 0.
>
> Does this mean Coverity is claiming that
> wait_for_completion_interruptible() can't return non-zero values? If
> so, can you figure out why Coverity thinks that? If that was true,
> it'd sound like a core kernel bug, rather than a uring issue...
Ah, nevermind, I missed the part where we only break out of the loop
if ret==0... sorry for the noise, ignore me.
On 10/8/20 12:23 PM, Colin Ian King wrote:
> Hi,
>
> Static analysis with Coverity has detected a "dead-code" issue with the
> following commit:
>
> commit af9c1a44f8dee7a958e07977f24ba40e3c770987
> Author: Jens Axboe <[email protected]>
> Date: Thu Sep 24 13:32:18 2020 -0600
>
> io_uring: process task work in io_uring_register()
>
> The analysis is as follows:
>
> 9513 do {
> 9514 ret =
> wait_for_completion_interruptible(&ctx->ref_comp);
>
> cond_const: Condition ret, taking false branch. Now the value of ret is
> equal to 0.
>
> 9515 if (!ret)
> 9516 break;
> 9517 if (io_run_task_work_sig() > 0)
> 9518 continue;
> 9519 } while (1);
> 9520
> 9521 mutex_lock(&ctx->uring_lock);
> 9522
>
> const: At condition ret, the value of ret must be equal to 0.
> dead_error_condition: The condition ret cannot be true.
Thanks, yeah that condition is reversed, should be:
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 4df5b14c2e56..80a0aa33db49 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -9511,8 +9511,8 @@ static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,
ret = wait_for_completion_interruptible(&ctx->ref_comp);
if (!ret)
break;
- if (io_run_task_work_sig() > 0)
- continue;
+ if (io_run_task_work_sig() <= 0)
+ break;
} while (1);
mutex_lock(&ctx->uring_lock);
--
Jens Axboe