Re: [GIT PULL] Driver core fixes for 7.1-rc1

["Danilo Krummrich" <dakr@kernel.org>]

On Sun Apr 19, 2026 at 10:28 PM CEST, Linus Torvalds wrote:
> Ugh. This just looks disgusting:
>
>         device_lock(dev);
>         dev_set_ready_to_probe(dev);
>         device_unlock(dev);
>
> when all it does is to just set a single bit.

It does look ugly indeed, but I think apart from that it is not that bad; the
device lock - except for the exact case where dev_ready_to_probe() is checked -
should otherwise be uncontended.

For context, in the original version of the patch it was just another C bitfield
at the end of struct device.

I noticed that this is racy as adjacent bitfield members are not all protected
by the same lock; subsequent patches from Doug (queued for 7.2) convert the C
bitfield over to this bitmap.

IOW, the atomic bitops are primarily an implementation detail to prevent
concurrent modifications of different flags from corrupting each other.

> Sadly, I think despite being disgusting, our bitop memory ordering
> models are incomplete.
>
> But I think dev_set_ready_to_probe() could/should use
> 'test_and_set_bit()', which turns the bit setting into strongly
> ordered (it only needs "release" consistency, but we don't have that).
>
> And the dev_ready_to_probe() should use "test_bit_acquire()".

To be honest, I did not consider this as we generate all accessors with a macro
and all other bits that we convert over from the struct device's C bitfields
would inherit these semantics.

Maybe that's not necessarily a bad thing though -- another option would be to
add dev_set_##accessor_name##_release() and dev_##accessor_name##_acquire().

- Danilo