From: Justin M. Forbes jforbes@fedoraproject.org
Turn CONFIG_DEVMEM back on for aarch64
We have ended up with a config mismatch for the RHEL configs in a way that was unclear and untracked. CONFIG_STRICT_DEVMEM is enabled in configs/common/generic, but CONFIG_DEVMEM was disabled for aarc64 in RHEL (though not in Fedora). This creates a mismatch situation where the configs do not get generated in the way they are set. Our options are to either turn on CONFIG_DEVMEM as I have here, or turn off CONFIG_STRICT_DEVMEM for aarch64. I went with the former, but I am happy to change this if needed, we just need the configs coherent.
Signed-off-by: Justin M. Forbes jforbes@fedoraproject.org
diff --git a/redhat/configs/ark/debug/arm/aarch64/CONFIG_DEVMEM b/redhat/configs/ark/debug/arm/aarch64/CONFIG_DEVMEM deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/debug/arm/aarch64/CONFIG_DEVMEM +++ /dev/null @@ -1 +0,0 @@ -CONFIG_DEVMEM=y diff --git a/redhat/configs/ark/generic/arm/aarch64/CONFIG_DEVMEM b/redhat/configs/ark/generic/arm/aarch64/CONFIG_DEVMEM deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/arm/aarch64/CONFIG_DEVMEM +++ /dev/null @@ -1 +0,0 @@ -# CONFIG_DEVMEM is not set diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM +++ /dev/null @@ -1 +0,0 @@ -CONFIG_DEVMEM=y
-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_7335424...
@ahs3 @mlangsdorf - any response to Justin's comment above?
From: Al Stone on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_7337285...
The problem as I understand it is that areas within /dev/mem may not actually have a current mapping to memory so the kernel can segfault, and that this can be SoC dependent; this is why dmidecode and all other such tools on aarch64 have been fixed so that there is no longer any reliance on /dev/mem at all. IIRC this was turned off in RHEL8 (and definitely well before that). My understanding could be incorrect, but that's what I recall.
From: Mark Langsdorf on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_7385939...
Acked-by: Mark Langsdorf mlangsdo@redhat.com (via approve button)
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_7902072...
@ahs3 @mlangsdorf - one wants this off the other is ok with it on. Help?
From: Mark Langsdorf on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_8021713...
Adding msalter in hopes he can clear this up.
On 05 Jan 2022 15:40, Mark Langsdorf (via Email Bridge) wrote:
From: Mark Langsdorf on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_8021713...
Adding msalter in hopes he can clear this up.
Excellent idea. I have two concerns: (1) why do we need to turn this on when upstream has worked so hard to turn it off? and (2) are we turning this on because there is a Customer need, or because the script for configs can't handle it? The former makes sense, but the latter would be puzzling to me. _______________________________________________
kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
From: Mark Salter on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_8023541...
Back in the RHELSA-7 days, we decided to turn off CONFIG_DEVMEM because certain userspace tools which were not sufficiently Arm-aware would crash the kernel. Someone (Applied Micro or Cavium) complained that there was debug value in having it enabled so we enabled it in -debug kernels. With RHEL-8, we missed the addition of STRICT_DEVMEM and it defaulted to =y even though DEVMEM was turned off so it didn't matter. Now we have DEVMEM enabled on RHEL-9 non- debug kernel. If we're going to leave it enabled, we want STRICT_DEVMEM=y so it's not so easy to crash the kernel. But turning DEVMEM on only for the -debug kernel makes the most sense to me.
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_8023693...
(2) are we turning this on because there is a Customer need, or because the
script for configs can't handle it? The former makes sense, but the latter would be puzzling to me.
The script for configs can handle any valid configs, the problem is you have an invalid config. As to what has been reviewed and approved, aarch64 would have CONFIG_DEVMEM off and CONFIG_STRICT_DEVMEM on. The later would silently flip CONFIG_DEVMEM to on, but our scripts alert us that it is happening and will not allow it because it is not what we have set.
If we're going to leave it enabled, we want STRICT_DEVMEM=y so it's not so
easy to crash the kernel. But turning DEVMEM on only for the -debug kernel makes the most sense to me.
I am happy to flip it back to off for aarch64 RHEL configs. The mismatch just has to be cleared up in one way or another. As it was, we had untracked files in pending-common.
kernel@lists.fedoraproject.org
-
Al Stone -
Al Stone (via Email Bridge) -
Don Zickus (via Email Bridge)
-
Justin M. Forbes (via Email Bridge)
-
Mark Langsdorf (via Email Bridge)
-
Mark Salter (via Email Bridge)