Revision 500f9fbadef86466a435726192f4ca4df7d94236 authored by Jens Axboe on 19 August 2019, 18:15:59 UTC, committed by Jens Axboe on 20 August 2019, 17:01:58 UTC
If a request issue ends up being punted to async context to avoid blocking, we can get into a situation where the original application enters the poll loop for that very request before it has been issued. This should not be an issue, except that the polling will hold the io_uring uring_ctx mutex for the duration of the poll. When the async worker has actually issued the request, it needs to acquire this mutex to add the request to the poll issued list. Since the application polling is already holding this mutex, the workqueue sleeps on the mutex forever, and the application thus never gets a chance to poll for the very request it was interested in. Fix this by ensuring that the polling drops the uring_ctx occasionally if it's not making any progress. Reported-by: Jeffrey M. Birnbaum <jmbnyc@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
1 parent d1abaeb
COPYING
The Linux Kernel is provided under:
SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
Being under the terms of the GNU General Public License version 2 only,
according with:
LICENSES/preferred/GPL-2.0
With an explicit syscall exception, as stated at:
LICENSES/exceptions/Linux-syscall-note
In addition, other licenses may also apply. Please see:
Documentation/process/license-rules.rst
for more details.
Computing file changes ...