From: Jens Axboe <[email protected]>
To: lizetao <[email protected]>, Pavel Begunkov <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH] test/defer: fix deadlock when io_uring_submit fail
Date: Sat, 18 Jan 2025 08:43:46 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 1/18/25 2:42 AM, lizetao wrote:
> Hi,
>
>> -----Original Message-----
>> From: Jens Axboe <[email protected]>
>> Sent: Thursday, January 16, 2025 10:51 PM
>> To: lizetao <[email protected]>; Pavel Begunkov <[email protected]>
>> Cc: [email protected]
>> Subject: Re: [PATCH] test/defer: fix deadlock when io_uring_submit fail
>>
>> On 1/15/25 6:10 AM, lizetao wrote:
>>> While performing fault injection testing, a bug report was triggered:
>>>
>>> FAULT_INJECTION: forcing a failure.
>>> name fail_usercopy, interval 1, probability 0, space 0, times 0
>>> CPU: 12 UID: 0 PID: 18795 Comm: defer.t Tainted: G O
>> 6.13.0-rc6-gf2a0a37b174b #17
>>> Tainted: [O]=OOT_MODULE
>>> Hardware name: linux,dummy-virt (DT)
>>> Call trace:
>>> show_stack+0x20/0x38 (C)
>>> dump_stack_lvl+0x78/0x90
>>> dump_stack+0x1c/0x28
>>> should_fail_ex+0x544/0x648
>>> should_fail+0x14/0x20
>>> should_fail_usercopy+0x1c/0x28
>>> get_timespec64+0x7c/0x258
>>> __io_timeout_prep+0x31c/0x798
>>> io_link_timeout_prep+0x1c/0x30
>>> io_submit_sqes+0x59c/0x1d50
>>> __arm64_sys_io_uring_enter+0x8dc/0xfa0
>>> invoke_syscall+0x74/0x270
>>> el0_svc_common.constprop.0+0xb4/0x240
>>> do_el0_svc+0x48/0x68
>>> el0_svc+0x38/0x78
>>> el0t_64_sync_handler+0xc8/0xd0
>>> el0t_64_sync+0x198/0x1a0
>>>
>>> The deadlock stack is as follows:
>>>
>>> io_cqring_wait+0xa64/0x1060
>>> __arm64_sys_io_uring_enter+0x46c/0xfa0
>>> invoke_syscall+0x74/0x270
>>> el0_svc_common.constprop.0+0xb4/0x240
>>> do_el0_svc+0x48/0x68
>>> el0_svc+0x38/0x78
>>> el0t_64_sync_handler+0xc8/0xd0
>>> el0t_64_sync+0x198/0x1a0
>>>
>>> This is because after the submission fails, the defer.t testcase is still waiting to
>> submit the failed request, resulting in an eventual deadlock.
>>> Solve the problem by telling wait_cqes the number of requests to wait for.
>>
>> I suspect this would be fixed by setting IORING_SETUP_SUBMIT_ALL for ring init,
>> something probably all/most tests should set.
>
>
> I tested it and found that IORING_SETUP_SUBMIT_ALL can indeed solve
> this problem. Should I just modify this problem or add
> IORING_SETUP_SUBMIT_ALL to the general path to solve most possible
> problems?
I think just fix up this one. We really should have all the tests use
t_create_ring*() first, and those helpers should just set SUBMIT_ALL.
But that's a separate change.
--
Jens Axboe
prev parent reply other threads:[~2025-01-18 15:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 13:10 [PATCH] test/defer: fix deadlock when io_uring_submit fail lizetao
2025-01-16 14:51 ` Jens Axboe
2025-01-18 9:42 ` lizetao
2025-01-18 15:43 ` Jens Axboe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox