On Thu, Aug 11, 2022 at 11:51:29AM -0600, Jens Axboe wrote:
>On 8/11/22 11:35 AM, Kanchan Joshi wrote:
>> On Thu, Aug 11, 2022 at 10:55:29AM -0600, Jens Axboe wrote:
>>> On 8/11/22 9:38 AM, Jens Axboe wrote:
>>>> On Thu, 11 Aug 2022 14:44:59 +0530, Anuj Gupta wrote:
>>>>> Commit 97b388d70b53 ("io_uring: handle completions in the core") moved the
>>>>> error handling from handler to core. But for io_uring_cmd handler we end
>>>>> up completing more than once (both in handler and in core) leading to
>>>>> use_after_free.
>>>>> Change io_uring_cmd handler to avoid calling io_uring_cmd_done in case
>>>>> of error.
>>>>>
>>>>> [...]
>>>>
>>>> Applied, thanks!
>>>>
>>>> [1/1] io_uring: fix error handling for io_uring_cmd
>>>>       commit: f1bb0fd63c374e1410ff05fb434aa78e1ce09ae4
>>>
>>> Ehm, did you compile this:
>> Sorry. Version that landed here got a upgrade in
>> commit-description but downgrade in this part :-(
>
>I fixed it up.

noticed, thanks.

>> BTW, we noticed the original issue while testing fixedbufs support.
>> Thinking to add a liburing test that involves sending a command which
>> nvme will fail during submission. Can come in handy.
>
>I think that's a good idea - if you had eg a NOP linked after a passthru
>command that failed, then that would catch this case.

Right. For now in liburing test we don't do anything that is guranteed
to fail from nvme-side. Test issues iopoll (that fails) but that failure
comes from io_uring itself (as .iopoll is not set). So another test that
will form a bad passthru command (e.g. wrong nsid) which only nvme can
(and will) fail.