linux-kernel - Re: [PATCH 0/4] cancel all reqs of an exiting task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7bbbb26c-6584-16d9-76c4-a2ca00d994f3@gmail.com>
Date:   Mon, 8 Jun 2020 10:35:34 +0300
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Jens Axboe <axboe@...nel.dk>, io-uring@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] cancel all reqs of an exiting task

On 08/06/2020 03:12, Jens Axboe wrote:
> On 6/7/20 9:32 AM, Pavel Begunkov wrote:
>> io_uring_flush() {
>>         ...
>>         if (fatal_signal_pending(current) || (current->flags & PF_EXITING))
>>                 io_wq_cancel_pid(ctx->io_wq, task_pid_vnr(current));
>> }
>>
>> This cancels only the first matched request. The pathset is mainly
>> about fixing that. [1,2] are preps, [3/4] is the fix.
>>
>> The [4/4] tries to improve the worst case for io_uring_cancel_files(),
>> that's when they are a lot of inflights with ->files. Instead of doing
>> {kill(); wait();} one by one, it cancels all of them at once.
>>
>> Pavel Begunkov (4):
>>   io-wq: reorder cancellation pending -> running
>>   io-wq: add an option to cancel all matched reqs
>>   io_uring: cancel all task's requests on exit
>>   io_uring: batch cancel in io_uring_cancel_files()
>>
>>  fs/io-wq.c    | 108 ++++++++++++++++++++++++++------------------------
>>  fs/io-wq.h    |   3 +-
>>  fs/io_uring.c |  29 ++++++++++++--
>>  3 files changed, 83 insertions(+), 57 deletions(-)
> 
> Can you rebase this to include the changing of using ->task_pid to
> ->task instead? See:
> 
> https://lore.kernel.org/io-uring/87a71jjbzr.fsf@x220.int.ebiederm.org/T/#u
> 
> Might as well do it at the same time, imho, since the cancel-by-task is
> being reworked anyway.

Ok, I was thinking to look there after anyway


-- 
Pavel Begunkov