linux-kernel - Re: [PATCH v2] atomics: fix atomic64_{read_acquire,set

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: <d8c546d-bf1e-5f7c-ab57-d56b12cf494d@tarent.de>
Date:   Mon, 7 Nov 2022 12:14:28 +0100 (CET)
From:   Thorsten Glaser <t.glaser@...ent.de>
To:     Mark Rutland <mark.rutland@....com>
cc:     linux-kernel@...r.kernel.org, ardb@...nel.org, arnd@...db.de,
        boqun.feng@...il.com, peterz@...radead.org, will@...nel.org
Subject: Re: [PATCH v2] atomics: fix atomic64_{read_acquire,set_release}
 fallbacks

On Mon, 7 Nov 2022, Mark Rutland wrote:

> Do you have a particular case in mind that you care about?

Definitely:

I have a qdisc which does rate limiting, and I need to update the
rate 100+ times a second and “tc qdisc change” introduces too much
delay (I *think* but I’m implementing this right now and we’ll see
whether this is indeed the problem).

The qdisc already uses relayfs over debugfs anyway to communicate
status info *to* userspace, so I’m adding another debugfs file and
will update the rate from its write fop.

So, after *much* reading and asking around, atomic64_set_release()
in the write fop, combined with atomic64_read_acquire() in the qdisc
hot path (which runs in softirq context and thus ought to be lockless)
seems to be “the answer”.

Basically, atomically changing a 64-bit value while keeping at least
the read part lockless was my requirement. (I’d be happy enough even
if the new value was read with _some_ delay, say within 1 µs, as long
as after the old value only the new value would be read, and never
a different value. Giving up ILP32 support for this is acceptable,
even if it may limit other uses later, although given this already
throws tons of u64 quantities around for nanoseconds it’d have sucked
on ILP32 already and I can tell the users to run it on LP64 only, it’s
for a specific use case only anyway.)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************