Vetter: Locking engineering hierarchy

[Posted August 3, 2022 by corbet]

Daniel Vetter continues his series on locking in the kernel.

This part goes through a pile of locking pattern and designs, from most favourable and easiest to adjust and hence resulting in a long term maintainable code base, to the least favourable since hardest to ensure it works correctly and stays that way while the code evolves. For convenience even color coded, with the dangerous levels getting progressively more crispy red indicating how close to the burning fire you are! Think of it as Dante’s Inferno, but for locking.

Vetter: Locking engineering hierarchy

Posted Aug 3, 2022 14:17 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Really nice, but I have one comment:

> Unlike e.g. C++ atomics in userspace they are unordered or weakly ordered by default in a lot of cases. A lot of people are surprised by that, and then have an even harder time understanding the memory barriers they need to sprinkle over the code to make it work correctly.

C++ atomics are "ordered but not quite": except for memory barriers, C++ seq_cst atomics are only ordered against other seq_cst atomics. The totally-ordered Linux atomics instead are ordered also against READ_ONCE and WRITE_ONCE.

The Linux atomics API is huge and unorthogonal, but the semantics are more pleasant to work with if you really need to. If you do not understand acquire/release or memory barriers, you probably shouldn't be using atomics either, so the complex API is not really a big deal. The most common uses of atomics are wrapped already in the kernel (e.g. kref_get_unless_zero or kref_put_mutex) anyway.

Vetter: Locking engineering hierarchy

Posted Aug 4, 2022 10:04 UTC (Thu) by epa (subscriber, #39769) [Link]

Reading his article, it sounds like the Linux codebase needs a flag day where all functions handling atomics are renamed to have 'atomic' in the name.

Vetter: Locking engineering hierarchy

Posted Aug 3, 2022 17:56 UTC (Wed) by estansvik (guest, #127963) [Link]

> In that case your cleanup code needs to somehow deal with these zombies and ensure there’s no confusion, and vice versa any code that resurrects a zombie needs to deal the wooden spikes the cleanup code might throw at an inopportune time.

No worries, spikes is a weapon against vampires and poses no threat to zombies. Had the cleanup code wielded a typical zombie weapon like an axe or machete, the resurrection code would indeed have to tread carefully.