All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>, Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast
Date: Wed, 11 Aug 2021 15:01:57 +0100	[thread overview]
Message-ID: <20210811140157.GA28658@e123427-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAMj1kXEB1CFj1svCWu7yOoUi_OkEqYEUQnB_XWOd3gD+ejO_6w@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Veronika kabatova <vkabatov@redhat.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>, Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast
Date: Wed, 11 Aug 2021 15:01:57 +0100	[thread overview]
Message-ID: <20210811140157.GA28658@e123427-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAMj1kXEB1CFj1svCWu7yOoUi_OkEqYEUQnB_XWOd3gD+ejO_6w@mail.gmail.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-08-11 14:02 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 10:00 [PATCH] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-07-26 10:00 ` Lorenzo Pieralisi
2021-07-26 15:55 ` Ard Biesheuvel
2021-07-26 15:55   ` Ard Biesheuvel
2021-07-27 10:06   ` Lorenzo Pieralisi
2021-07-27 10:06     ` Lorenzo Pieralisi
2021-07-27 10:09     ` Ard Biesheuvel
2021-07-27 10:09       ` Ard Biesheuvel
2021-07-27 16:38       ` Lorenzo Pieralisi
2021-07-27 16:38         ` Lorenzo Pieralisi
2021-07-27  4:21 ` Hanjun Guo
2021-07-27  4:21   ` Hanjun Guo
2021-08-02 15:23 ` [PATCH v2 0/3] ACPI: Fix acpi_os_map_memory() memory semantics Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 15:37   ` Ard Biesheuvel
2021-08-02 15:37     ` Ard Biesheuvel
2021-08-23 10:35   ` [PATCH v3] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-08-23 10:46   ` [PATCH RESEND " Lorenzo Pieralisi
2021-08-23 10:46     ` Lorenzo Pieralisi
2021-08-23 12:30     ` Catalin Marinas
2021-08-23 12:30       ` Catalin Marinas
2021-08-25 17:46       ` Rafael J. Wysocki
2021-08-25 17:46         ` Rafael J. Wysocki
2021-08-02 15:23 ` [PATCH v2 1/3] ACPI: osl: Add __force attribute in acpi_os_map_iomem() cast Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-10 16:45   ` Christoph Hellwig
2021-08-10 16:45     ` Christoph Hellwig
2021-08-11 10:40     ` Ard Biesheuvel
2021-08-11 10:40       ` Ard Biesheuvel
2021-08-11 14:01       ` Lorenzo Pieralisi [this message]
2021-08-11 14:01         ` Lorenzo Pieralisi
2021-08-11 14:08       ` Christoph Hellwig
2021-08-11 14:08         ` Christoph Hellwig
2021-08-11 14:55         ` Lorenzo Pieralisi
2021-08-11 14:55           ` Lorenzo Pieralisi
2021-08-16  9:58           ` Lorenzo Pieralisi
2021-08-16  9:58             ` Lorenzo Pieralisi
2021-08-16 10:21             ` Ard Biesheuvel
2021-08-16 10:21               ` Ard Biesheuvel
2021-08-16 10:59               ` Robin Murphy
2021-08-16 10:59                 ` Robin Murphy
2021-08-16 13:57               ` Rafael J. Wysocki
2021-08-16 13:57                 ` Rafael J. Wysocki
2021-08-02 15:23 ` [PATCH v2 2/3] ACPI: osl: Reorder acpi_os_map_iomem() __ref annotation Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 15:23 ` [PATCH v2 3/3] ACPI: Add memory semantics to acpi_os_map_memory() Lorenzo Pieralisi
2021-08-02 15:23   ` Lorenzo Pieralisi
2021-08-02 16:46   ` Catalin Marinas
2021-08-02 16:46     ` Catalin Marinas
2021-08-03  9:16     ` Lorenzo Pieralisi
2021-08-03  9:16       ` Lorenzo Pieralisi
2021-08-05 19:02       ` Rafael J. Wysocki
2021-08-05 19:02         ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210811140157.GA28658@e123427-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=hch@infradead.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=robin.murphy@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vkabatov@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.