linux-kernel - Re: [RFC][PATCH v2 08/10] smp,irq_work: Use the new irq

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]

Date:   Wed, 9 Sep 2020 10:03:36 +0200
From:   Christoph Hellwig <hch@....de>
To:     peterz@...radead.org
Cc:     Christoph Hellwig <hch@....de>, mingo@...nel.org,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        will@...nel.org, paulmck@...nel.org, axboe@...nel.dk,
        chris@...is-wilson.co.uk, davem@...emloft.net, kuba@...nel.org,
        fweisbec@...il.com, oleg@...hat.com, vincent.guittot@...aro.org
Subject: Re: [RFC][PATCH v2 08/10] smp,irq_work: Use the new irq_work API

On Thu, Aug 20, 2020 at 03:40:01PM +0200, peterz@...radead.org wrote:
> Anyway, tl;dr, what do we actually want? Do we favour the embedded
> irq_work variant over smp_call_function_single_asyn() ?

For blk-mq we really like an embedded structure that allows to bounce
the work to another CPU using IPIs.

> There's a few subtle differences, where smp_call_function_single_async()
> will directly call @func when @cpu == smp_processor_id(),
> irq_work_remote will give you WARN -- since irq_work to the local CPU is
> defined as a self-IPI, which isn't implemented on all architectures and
> is a distinctly different behaviour.

For the block code we handle the self case explicitly as it allows us
to optimize further and avoid an indirect call.  That being said we
don't do a preempt_disable for that any more, as completing on the
"wrong" CPU for a just migrated completion handler is at worst a
performance degration but not a functional issue.  So instead of the
warn we'd at least like an error return that allows to directly call
the completion handler.