On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote:

On Tue, 10 Aug 2021 at 18:46, Christoph Hellwig [off-list ref] wrote:

quoted

On Mon, Aug 02, 2021 at 04:23:57PM +0100, Lorenzo Pieralisi wrote:

quoted

Add a __force attribute to the void* cast in acpi_os_map_iomem()
to prevent sparse warnings.

Err, no.  These annotation are there for a reason and need to
be propagated instead.  And independent of that a __force cast
without a comment explaining it is a complete no-go.

The whole problem we are solving here is that ACPI, being based on
x86, conflates MMIO mappings with memory mappings, and has been using
the same underlying infrastructure for either. On arm64, this is not
sufficient, given that the semantics of uncached memory vs device are
different (the former permits unaligned accesses and clear cacheline
instructions, but the latter doesn't). A recent optimization applied
to memcpy() on arm64 (which now relies more on unaligned accesses for
performance) has uncovered an issue where firmware tables being mapped
non-cacheable by the ACPI core will end up using device mappings,
which causes memcpy() to choke on their contents.

So propagating the annotation makes no sense, as we are creating a
memory mapping using the iomem primitive. I wouldn't object to a
comment being added, but I think the context should have been obvious
to anyone who had bothered to look at the entire series.

I can add a comment and respin. Basically a __force attribute is
added to ignore a sparse warning that's been ignored for aeons
anyway - I will add the rationale above.

drivers/acpi/osl.c:379:17: warning: cast removes address space '__iomem' of expression