linux-kernel - [RFC][PATCH 0/9] smp: irq_work / smp_call

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-next>] [day] [month] [year] [list]

Message-ID: <20200722150149.525408253@infradead.org>
Date:   Wed, 22 Jul 2020 17:01:49 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     mingo@...nel.org, torvalds@...ux-foundation.org
Cc:     linux-kernel@...r.kernel.org, will@...nel.org, paulmck@...nel.org,
        hch@....de, axboe@...nel.dk, chris@...is-wilson.co.uk,
        davem@...emloft.net, kuba@...nel.org, fweisbec@...il.com,
        oleg@...hat.com, peterz@...radead.org
Subject: [RFC][PATCH 0/9] smp: irq_work / smp_call_function rework

Hi,

Here are a number of patches that continue the irq_work / smp_call_function
integration / cleanup.

One of the biggest warts in this area is smp_call_function_single_async(); it
looks like a useful function but is incredibly hard to use correctly due to the
test-and-set LOCK on the csd not being atomic. This means you need to be
incredibly careful to not corrupt the csd.

Simple patterns like allowing any CPU to IPI any other CPU end up requiring
nr_cpu^2 storage because of this.

On top of that the csd has external data, vs the more common internal/embedded
data pattern.

Now, irq_work has the embedded data pattern, but requires arch support for
self-IPI. But because irq_work for remote CPUs relies on the smp_call_function
infrastructure we can implement a generic irq_work_queue_remote().

Then it goes a bit ugly, and I introduce irq_work_queue_remote_static() that is
non-atomic in exactly the same way smp_call_function_single_async() is now, but
at least it has embedded data. A few performance sensitive users of
smp_call_function_single_async() are converted.

Finally, smp_call_function_single_async() is made safer by using an atomic
test-and-set.

TL;DR, I think at least the first few patches should go in the next round, but
the rest can use some feedback.