diff options
| author | Hao Xu <[email protected]> | 2021-08-05 10:05:37 +0000 |
|---|---|---|
| committer | Jens Axboe <[email protected]> | 2021-08-06 14:27:54 +0000 |
| commit | 3d4e4face9c1548752a2891e98b38b100feee336 (patch) | |
| tree | d244adacc9c6e3f35303953ec242ba2a6cb47a20 /lib/debugobjects.c | |
| parent | io-wq: fix race between worker exiting and activating free worker (diff) | |
| download | kernel-3d4e4face9c1548752a2891e98b38b100feee336.tar.gz kernel-3d4e4face9c1548752a2891e98b38b100feee336.zip | |
io-wq: fix no lock protection of acct->nr_worker
There is an acct->nr_worker visit without lock protection. Think about
the case: two callers call io_wqe_wake_worker(), one is the original
context and the other one is an io-worker(by calling
io_wqe_enqueue(wqe, linked)), on two cpus paralelly, this may cause
nr_worker to be larger than max_worker.
Let's fix it by adding lock for it, and let's do nr_workers++ before
create_io_worker. There may be a edge cause that the first caller fails
to create an io-worker, but the second caller doesn't know it and then
quit creating io-worker as well:
say nr_worker = max_worker - 1
cpu 0 cpu 1
io_wqe_wake_worker() io_wqe_wake_worker()
nr_worker < max_worker
nr_worker++
create_io_worker() nr_worker == max_worker
failed return
return
But the chance of this case is very slim.
Fixes: 685fe7feedb9 ("io-wq: eliminate the need for a manager thread")
Signed-off-by: Hao Xu <[email protected]>
[axboe: fix unconditional create_io_worker() call]
Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'lib/debugobjects.c')
0 files changed, 0 insertions, 0 deletions
