Commit fd63836811d6e5b5f5f608abf865bc9e91762c8c

Authored by Tejun Heo
Committed by Jens Axboe
1 parent 64c42998f1

block: an exiting task should be allowed to create io_context

While fixing io_context creation / task exit race condition,
6e736be7f2 "block: make ioc get/put interface more conventional and
fix race on alloction" also prevented an exiting (%PF_EXITING) task
from creating its own io_context.  This is incorrect as exit path may
issue IOs, e.g. from exit_files(), and if those IOs are the first ones
issued by the task, io_context needs to be created to process the IOs.

Combined with the existing problem of io_context / io_cq creation
failure having the possibility of stalling IO, this problem results in
deterministic full IO lockup with certain workloads.

Fix it by allowing io_context creation regardless of %PF_EXITING for
%current.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Showing 1 changed file with 9 additions and 2 deletions Side-by-side Diff

... ... @@ -281,9 +281,16 @@
281 281 INIT_HLIST_HEAD(&ioc->icq_list);
282 282 INIT_WORK(&ioc->release_work, ioc_release_fn);
283 283  
284   - /* try to install, somebody might already have beaten us to it */
  284 + /*
  285 + * Try to install. ioc shouldn't be installed if someone else
  286 + * already did or @task, which isn't %current, is exiting. Note
  287 + * that we need to allow ioc creation on exiting %current as exit
  288 + * path may issue IOs from e.g. exit_files(). The exit path is
  289 + * responsible for not issuing IO after exit_io_context().
  290 + */
285 291 task_lock(task);
286   - if (!task->io_context && !(task->flags & PF_EXITING))
  292 + if (!task->io_context &&
  293 + (task == current || !(task->flags & PF_EXITING)))
287 294 task->io_context = ioc;
288 295 else
289 296 kmem_cache_free(iocontext_cachep, ioc);