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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 7 Sep 2022 07:44:05 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Bart Van Assche <bvanassche@....org>,
        Ming Lei <ming.lei@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] kernel: export task_work_add

On 9/7/22 7:08 AM, Bart Van Assche wrote:
> On 8/28/22 21:00, Ming Lei wrote:
>> Firstly task_work_add() is used in several drivers. In ublk driver's
>> usage, request batching submission can only be applied with task_work_add,
>> and usually get better IOPS.
>>
>> Secondly from this API's definition, the added work is always run in
>> the task context, and when task is exiting, either the work is rejected
>> to be added, or drained in do_exit(). In this way, not see obvious
>> disadvantage or potential issue by exporting it for module's usage.
>>
>> So export it, then ublk driver can get simplified, meantime with better
>> performance.
> 
> If task_work_add() is exported, shouldn't task_work_cancel() be exported
> too? Anyway:

Not if it isn't currently used...

On the patch itself, it definitely makes sense in the context of ublk.
My hesitation is mostly around not really wanting to export this to
generic modular users. It's OK for core interfaces, of which ublk is
on the way to becoming, but I really don't like the idea of random
modules using it. But that's not really something we can manage with
the export, it's either exported or it's not...

-- 
Jens Axboe


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ