[PATCH v2 4/6] firmware: samsung: acpm: Fix memory ordering race in RX path

[Krzysztof Kozlowski]

On 27/04/2026 17:04, Tudor Ambarus wrote:
> Sashiko identified a memory ordering race in RX path [1].
> 
> When draining the RX queue or reading saved responses, the driver uses
> clear_bit() to release the sequence number back to the available pool.
> However, on weakly ordered architectures like ARM64, clear_bit() does
> not provide implicit memory barriers.

And it does not have to if entire access is synchronized by other locks.
You need to analyze also this and mention here path which is not
synchronized and uses these weakly ordered atomic operations.

> 
> This allows the CPU to reorder instructions, making the cleared bit
> globally visible before the preceding memory operations (memcpy() or
> __ioread32_copy()) have completed. If a concurrent thread allocates the
> newly freed sequence number, it can execute acpm_prepare_xfer() and
> zero out the buffer via memset() while the RX thread is still actively
> reading from it, leading to silent data corruption.
> 
> Fix this by replacing clear_bit() with clear_bit_unlock() across the
> RX path. This provides release semantics, guaranteeing that all prior
> memory reads and writes are fully completed and visible before the
> sequence number is marked as free.

Barriers should be paired and release is paired with acquire.
bitmap_seqnum() is used with test_bit() and a separate set_bit(), which
do not have acquire semantics, although in some calls it is within lock.
Problem is I guess acpm_dequeue_by_polling() which is called without any
locks.

This means that other thread won't see updated values.

I think you also need to investigate and fix that acquire path.

Best regards,
Krzysztof