[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66945bc6-e567-b5a8-9b4d-2b620cf1bdc5@gmail.com>
Date: Mon, 15 Aug 2022 15:09:50 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Stefan Metzmacher <metze@...ba.org>, io-uring@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: "David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Willem de Bruijn <willemb@...gle.com>,
Jens Axboe <axboe@...nel.dk>, kernel-team@...com
Subject: Re: [RFC net-next v3 23/29] io_uring: allow to pass addr into sendzc
On 8/15/22 14:30, Stefan Metzmacher wrote:
[...]
>>> that causes io_ring_exit_work() to wait for it.> It would be great if you or someone else could explain this in detail
>>> and maybe adding some comments into the code.
>>
>> Almost, the mechanism is absolutely the same as with requests,
>> and notifiers are actually requests for internal purposes.
>>
>> In __io_alloc_req_refill() we grab ctx->refs, which are waited
>> for in io_ring_exit_work(). We usually put requests into a cache,
>> so when a request is complete we don't put the ref and therefore
>> in io_ring_exit_work() we also have a call to io_req_caches_free(),
>> which puts ctx->refs.
>
> Ok, thanks.
>
> Would a close() on the ring fd block? I guess not, but the exit_work may block, correct?
Right, close doesn't block, it queues exit_work to get executed async.
exit_work() will wait for ctx->refs and then will free most of
io_uring resources.
> So a process would be a zombie until net released all references?
The userspace process will exit normally, but you can find a kernel
thread (kworker) doing the job.
--
Pavel Begunkov
Powered by blists - more mailing lists