Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Aristeu Rozanski <aris@redhat.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: ??? FAIL: Test report for kernel 5.13.0-rc7 (arm-next, 8ab9b1a9)
Date: Mon, 7 Mar 2022 10:19:07 +0000	[thread overview]
Message-ID: <YiXb9QEIFoxSjy4N@lpieralisi> (raw)
In-Reply-To: <20220304193920.kj3mvrguepklgb3m@redhat.com>

On Fri, Mar 04, 2022 at 02:39:20PM -0500, Aristeu Rozanski wrote:
> Hi Robin,
> 
> (Old thread, so reference to it: https://lists.infradead.org/pipermail/linux-arm-kernel/2021-June/668228.html)
> (Also, please keep me on Cc since I'm not subscribed to linux-arm)
> (And again because I failed to fix the email address after using the
> archives mailbox, apologies for that)
> 
> On Tue, Jun 29, 2021 at 06:27:57PM +0100, Robin Murphy wrote:
> > Ah, from that I can only assume that this must be stress-ng's --sysfs 
> > test reading things at random, so not only would it have to be on a 
> > machine whose firmware presents the right thing in the right way but the 
> > random test conditions would also have to line up to poke it the "right" 
> > (wrong) way too.
> > 
> > As a temporary workaround for the CI flakes, might it be possible to 
> > configure stress-ng to stay away from just these ACPI "data" files?
> 
> I started looking at this issue and managed to reproduce the issue
> instantly with
> 
> 	dd if=/sys/firmware/acpi/tables/data/BERT of=/dev/null bs=7
> 
> I've attempted a few ways of fixing it based on the comments on this
> thread but wasn't successful so far (my knowledge is pretty limited in
> this area too, so not a big surprise). How can I be of assistance to debug/test
> patches for this issue?

I put together the patch below that I need to send to see whether
that's acceptable, if you can help me test it in the meantime, that'd
great.

-- >8 --
Subject: [PATCH] ACPI: osl: Fix BERT error region memory mapping

Currently the sysfs interface maps the BERT error region as "memory"
(through acpi_os_map_memory()) in order to copy the error records into
memory buffers through memory operations (eg memory_read_from_buffer()).

The OS system cannot detect whether the BERT error region is part of
system RAM or it is "device memory" (eg BMC memory) and therefore it
cannot detect which memory attributes the bus to memory support (and
corresponding kernel mapping, unless firmware provides the required
information).

The acpi_os_map_memory() arch backend implementation determines the
mapping attributes. On arm64, if the BERT error region is not present in
the EFI memory map, the error region is mapped as device-nGnRnE; this
triggers alignment faults since memcpy unaligned accesses are not
allowed in device-nGnRnE regions.

The ACPI sysfs code cannot therefore map by default the BERT error
region with memory semantics but should use a safer default.

Change the sysfs code to map the BERT error region as MMIO (through
acpi_os_map_iomem()) and use the memcpy_fromio() interface to read the
error region into the kernel buffer.

Link: https://lore.kernel.org/linux-arm-kernel/31ffe8fc-f5ee-2858-26c5-0fd8bdd68702@arm.com
Link: https://lore.kernel.org/linux-acpi/CAJZ5v0g+OVbhuUUDrLUCfX_mVqY_e8ubgLTU98=jfjTeb4t+Pw@mail.gmail.com
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
 drivers/acpi/sysfs.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index a4b638bea6f1..cc2fe0618178 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -415,19 +415,30 @@ static ssize_t acpi_data_show(struct file *filp, struct kobject *kobj,
 			      loff_t offset, size_t count)
 {
 	struct acpi_data_attr *data_attr;
-	void *base;
-	ssize_t rc;
+	void __iomem *base;
+	ssize_t size;
 
 	data_attr = container_of(bin_attr, struct acpi_data_attr, attr);
+	size = data_attr->attr.size;
+
+	if (offset < 0)
+		return -EINVAL;
+
+	if (offset >= size)
+		return 0;
 
-	base = acpi_os_map_memory(data_attr->addr, data_attr->attr.size);
+	if (count > size - offset)
+		count = size - offset;
+
+	base = acpi_os_map_iomem(data_attr->addr, size);
 	if (!base)
 		return -ENOMEM;
-	rc = memory_read_from_buffer(buf, count, &offset, base,
-				     data_attr->attr.size);
-	acpi_os_unmap_memory(base, data_attr->attr.size);
 
-	return rc;
+	memcpy_fromio(buf, base + offset, count);
+
+	acpi_os_unmap_iomem(base, size);
+
+	return count;
 }
 
 static int acpi_bert_data_init(void *th, struct acpi_data_attr *data_attr)
-- 
2.17.1


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

  parent reply	other threads:[~2022-03-07 10:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 19:46 ❌ FAIL: Test report for kernel 5.13.0-rc7 (arm-next, 8ab9b1a9) CKI Project
2021-06-25  8:39 ` Will Deacon
     [not found]   ` <CA+tGwn=rP_hAMLLtoy_s90ZzBjfMggu7T2Qj8HyFfGh1BGUoRA@mail.gmail.com>
2021-06-25 11:02     ` Robin Murphy
2021-06-25 11:09       ` Catalin Marinas
2021-06-25 11:15         ` Robin Murphy
2021-06-29 11:48           ` Robin Murphy
2021-06-29 14:44             ` Lorenzo Pieralisi
2021-06-29 15:14               ` Robin Murphy
2021-06-29 16:35                 ` Catalin Marinas
2021-06-30 10:37                   ` Lorenzo Pieralisi
2021-06-30 11:17                     ` Robin Murphy
     [not found]                       ` <CAMj1kXH=Q+WNgGsbApiq94z5OpJOnNLcFk_dyoVm_-VQunv3MA@mail.gmail.com>
2021-06-30 15:49                         ` Lorenzo Pieralisi
     [not found]                           ` <CAMj1kXHgPmJV6sPO8OWYj84Ncts00fzn+gJ=+xzcXYhCxvm-aA@mail.gmail.com>
2021-07-05 16:17                             ` Lorenzo Pieralisi
     [not found]                               ` <CAMj1kXHQKKnzJUEXMMzt3D1NUodeik8FZN1OTpD9zf8ZWrp6Lw@mail.gmail.com>
2021-07-16 16:26                                 ` Lorenzo Pieralisi
     [not found]                                   ` <CA+tGwnmu-uL1v3vWO1yzH1i1ru6+EbVdEKnGOifoS6fLuTTGoQ@mail.gmail.com>
2021-07-22 13:51                                     ` Robin Murphy
     [not found]                 ` <CA+tGwn=r=BZK08CHBUkk1m5NB-W7GqC9Cwj6Qj+_MbYzqdEjDg@mail.gmail.com>
2021-06-29 17:27                   ` Robin Murphy
2022-03-04 19:31                     ` ??? " Aristeu Rozanski
2022-03-04 19:39                     ` Aristeu Rozanski
2022-03-04 20:00                       ` Robin Murphy
2022-03-07 10:19                       ` Lorenzo Pieralisi [this message]
2022-03-07 19:01                         ` Aristeu Rozanski

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=YiXb9QEIFoxSjy4N@lpieralisi \
    --to=lorenzo.pieralisi@arm.com \
    --cc=aris@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox