diff mbox series

[v2,1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast

Message ID 20210802152359.12623-2-lorenzo.pieralisi@arm.com
State New
Headers show
Series [v2,1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast | expand

Commit Message

Lorenzo Pieralisi Aug. 2, 2021, 3:23 p.m. UTC 
Add a __force attribute to the void* cast in acpi_os_map_iomem()
to prevent sparse warnings.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
 drivers/acpi/osl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.31.0

Comments

'Christoph Hellwig' Aug. 10, 2021, 4:45 p.m. UTC | #1 
On Mon, Aug 02, 2021 at 04:23:57PM +0100, Lorenzo Pieralisi wrote:
> 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.
Ard Biesheuvel Aug. 11, 2021, 10:40 a.m. UTC | #2 
On Tue, 10 Aug 2021 at 18:46, Christoph Hellwig <hch@infradead.org> wrote:
>

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

> > 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.
Lorenzo Pieralisi Aug. 11, 2021, 2:01 p.m. UTC | #3 
On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote:
> On Tue, 10 Aug 2021 at 18:46, Christoph Hellwig <hch@infradead.org> wrote:

> >

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

> > > 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
'Christoph Hellwig' Aug. 11, 2021, 2:08 p.m. UTC | #4 
On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote:
> 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.


So let's fix that problem instead of papering over it.
Lorenzo Pieralisi Aug. 11, 2021, 2:55 p.m. UTC | #5 
On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 11, 2021 at 12:40:28PM +0200, Ard Biesheuvel wrote:

> > 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.

> 

> So let's fix that problem instead of papering over it.


Patch (3) in this series is a fix - I would ask whether it makes
sense to merge patches (2-3) now and think about reworking the current
ACPI IO/MEM mapping API later, it can be an invasive change for a fix,
assuming we agree on how to rework the ACPI IO/MEM mapping API.

Lorenzo
Lorenzo Pieralisi Aug. 16, 2021, 9:58 a.m. UTC | #6 
On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:

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

> > > 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.

> > 

> > So let's fix that problem instead of papering over it.

> 

> Patch (3) in this series is a fix - I would ask whether it makes

> sense to merge patches (2-3) now and think about reworking the current

> ACPI IO/MEM mapping API later, it can be an invasive change for a fix,

> assuming we agree on how to rework the ACPI IO/MEM mapping API.


What should we do then with this series ?

Thanks,
Lorenzo
Ard Biesheuvel Aug. 16, 2021, 10:21 a.m. UTC | #7 
On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>

> On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote:

> > On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:

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

> > > > 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.

> > >

> > > So let's fix that problem instead of papering over it.

> >

> > Patch (3) in this series is a fix - I would ask whether it makes

> > sense to merge patches (2-3) now and think about reworking the current

> > ACPI IO/MEM mapping API later, it can be an invasive change for a fix,

> > assuming we agree on how to rework the ACPI IO/MEM mapping API.

>

> What should we do then with this series ?

>


It is not even clear that reworking the ACPI core is feasible to begin
with, OTOH, fixing a sparse warning is arguably not a critical bug fix
either, so I'd suggest we just drop that bit.
Robin Murphy Aug. 16, 2021, 10:59 a.m. UTC | #8 
On 2021-08-16 11:21, Ard Biesheuvel wrote:
> On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi

> <lorenzo.pieralisi@arm.com> wrote:

>>

>> On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote:

>>> On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:

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

>>>>> 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.

>>>>

>>>> So let's fix that problem instead of papering over it.

>>>

>>> Patch (3) in this series is a fix - I would ask whether it makes

>>> sense to merge patches (2-3) now and think about reworking the current

>>> ACPI IO/MEM mapping API later, it can be an invasive change for a fix,

>>> assuming we agree on how to rework the ACPI IO/MEM mapping API.

>>

>> What should we do then with this series ?

>>

> 

> It is not even clear that reworking the ACPI core is feasible to begin

> with, OTOH, fixing a sparse warning is arguably not a critical bug fix

> either, so I'd suggest we just drop that bit.


Indeed, the only way to truly fix the issue is to fire up the time 
machine and rewrite the ACPI and EFI specs to not define that tables and 
data may or may not be required to be mapped as Device memory depending 
on the whims of the firmware. Otherwise we're basically always going to 
have one or more casts *somewhere*, even if we were to play it safe and 
return everything as iomem instead.

I guess for read-only access to tables, the core code might be able to 
maintain a shadow copy of anything device-memory-mapped in normal memory 
and expose that instead, but if anything has to be writeable I'm not 
sure how we could abstract that "properly".

Robin.
Rafael J. Wysocki Aug. 16, 2021, 1:57 p.m. UTC | #9 
On Mon, Aug 16, 2021 at 12:22 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>

> On Mon, 16 Aug 2021 at 11:59, Lorenzo Pieralisi

> <lorenzo.pieralisi@arm.com> wrote:

> >

> > On Wed, Aug 11, 2021 at 03:55:08PM +0100, Lorenzo Pieralisi wrote:

> > > On Wed, Aug 11, 2021 at 03:08:24PM +0100, Christoph Hellwig wrote:

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

> > > > > 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.

> > > >

> > > > So let's fix that problem instead of papering over it.

> > >

> > > Patch (3) in this series is a fix - I would ask whether it makes

> > > sense to merge patches (2-3) now and think about reworking the current

> > > ACPI IO/MEM mapping API later, it can be an invasive change for a fix,

> > > assuming we agree on how to rework the ACPI IO/MEM mapping API.

> >

> > What should we do then with this series ?

> >

>

> It is not even clear that reworking the ACPI core is feasible to begin

> with, OTOH, fixing a sparse warning is arguably not a critical bug fix

> either, so I'd suggest we just drop that bit.


So I'm assuming that one more iteration of this series will be posted.
diff mbox series

Patch

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 45c5c0e45e33..8f67bf0f090b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -376,7 +376,7 @@  EXPORT_SYMBOL_GPL(acpi_os_map_iomem);
 
 void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
 {
-	return (void *)acpi_os_map_iomem(phys, size);
+	return (__force void *)acpi_os_map_iomem(phys, size);
 }
 EXPORT_SYMBOL_GPL(acpi_os_map_memory);