* io_close()
@ 2020-02-07 20:52 Pavel Begunkov
2020-02-07 21:14 ` io_close() Jens Axboe
0 siblings, 1 reply; 4+ messages in thread
From: Pavel Begunkov @ 2020-02-07 20:52 UTC (permalink / raw)
To: Jens Axboe, io-uring
[-- Attachment #1.1: Type: text/plain, Size: 297 bytes --]
Hi,
I noticed, that io_close() is broken for some use cases, and was thinking about
the best way to fix it. Is fput(req->close.put_file) really need to be done in
wq? It seems, fput_many() implementation just calls schedule_delayed_work(), so
it's already delayed.
--
Pavel Begunkov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: io_close()
2020-02-07 20:52 io_close() Pavel Begunkov
@ 2020-02-07 21:14 ` Jens Axboe
2020-02-07 21:19 ` io_close() Pavel Begunkov
2020-02-07 21:35 ` io_close() Pavel Begunkov
0 siblings, 2 replies; 4+ messages in thread
From: Jens Axboe @ 2020-02-07 21:14 UTC (permalink / raw)
To: Pavel Begunkov, io-uring
On 2/7/20 1:52 PM, Pavel Begunkov wrote:
> Hi,
>
> I noticed, that io_close() is broken for some use cases, and was thinking about
> the best way to fix it. Is fput(req->close.put_file) really need to be done in
> wq? It seems, fput_many() implementation just calls schedule_delayed_work(), so
> it's already delayed.
It's not the fput(), it's the f_op->flush().
--
Jens Axboe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: io_close()
2020-02-07 21:14 ` io_close() Jens Axboe
@ 2020-02-07 21:19 ` Pavel Begunkov
2020-02-07 21:35 ` io_close() Pavel Begunkov
1 sibling, 0 replies; 4+ messages in thread
From: Pavel Begunkov @ 2020-02-07 21:19 UTC (permalink / raw)
To: Jens Axboe, io-uring
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
On 08/02/2020 00:14, Jens Axboe wrote:
> On 2/7/20 1:52 PM, Pavel Begunkov wrote:
>> Hi,
>>
>> I noticed, that io_close() is broken for some use cases, and was thinking about
>> the best way to fix it. Is fput(req->close.put_file) really need to be done in
>> wq? It seems, fput_many() implementation just calls schedule_delayed_work(), so
>> it's already delayed.
>
> It's not the fput(), it's the f_op->flush().
>
Got it, thanks
--
Pavel Begunkov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: io_close()
2020-02-07 21:14 ` io_close() Jens Axboe
2020-02-07 21:19 ` io_close() Pavel Begunkov
@ 2020-02-07 21:35 ` Pavel Begunkov
1 sibling, 0 replies; 4+ messages in thread
From: Pavel Begunkov @ 2020-02-07 21:35 UTC (permalink / raw)
To: Jens Axboe, io-uring
[-- Attachment #1.1: Type: text/plain, Size: 711 bytes --]
On 08/02/2020 00:14, Jens Axboe wrote:
> On 2/7/20 1:52 PM, Pavel Begunkov wrote:
>> Hi,
>>
>> I noticed, that io_close() is broken for some use cases, and was thinking about
>> the best way to fix it. Is fput(req->close.put_file) really need to be done in
>> wq? It seems, fput_many() implementation just calls schedule_delayed_work(), so
>> it's already delayed.
>
> It's not the fput(), it's the f_op->flush().
What confuses me, is that in case of ->flush, it doesn't return -EAGAIN, but
io_queue_async_work() itself, so nobody will set ->work.files. But that means
io_close_finish() won't do filp_close() as well.
Did I missed somewhere called io_grab_files()?
--
Pavel Begunkov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-07 21:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-07 20:52 io_close() Pavel Begunkov
2020-02-07 21:14 ` io_close() Jens Axboe
2020-02-07 21:19 ` io_close() Pavel Begunkov
2020-02-07 21:35 ` io_close() Pavel Begunkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox