From: Will Deacon <will@kernel.org> Date: 2021-05-27 12:45:39
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a55b ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vincent Whitchurch <redacted>
Link: https://lore.kernel.org/linux-arm-kernel/1442944788-17254-1-git-send-email-rric@kernel.org/
Link: https://lore.kernel.org/linux-arm-kernel/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com/
Link: https://lore.kernel.org/linux-arm-kernel/20190614131141.4428-1-msys.mizuma@gmail.com/
Link: https://lore.kernel.org/r/20210517074332.28280-1-vincent.whitchurch@axis.com
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/cache.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, May 27, 2021 at 01:43:56PM +0100, Will Deacon wrote:
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a55b ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vincent Whitchurch <redacted>
Link: https://lore.kernel.org/linux-arm-kernel/1442944788-17254-1-git-send-email-rric@kernel.org/
Link: https://lore.kernel.org/linux-arm-kernel/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com/
Link: https://lore.kernel.org/linux-arm-kernel/20190614131141.4428-1-msys.mizuma@gmail.com/
Link: https://lore.kernel.org/r/20210517074332.28280-1-vincent.whitchurch@axis.com
Signed-off-by: Will Deacon <will@kernel.org>
Unless we hear from anyone that the warning is triggered, I think we
should change this in mainline.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-05-27 13:29:23
On Thu, May 27, 2021 at 01:43:56PM +0100, Will Deacon wrote:
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a55b ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
The rationale above makes sense to me, so:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
On Thu, May 27, 2021 at 3:19 PM Mark Rutland [off-list ref] wrote:
quoted
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
The rationale above makes sense to me, so:
Acked-by: Mark Rutland <mark.rutland@arm.com>
I think it would make sense to go even further than this in the
future, and allow
setting a smaller minimum alignment depending what hardware is detected
at boot time. That would clearly require more work and testing to do right,
so for the moment, this approach is the best we can do.
Acked-by: Arnd Bergmann <arnd@arndb.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, 27 May 2021 at 14:44, Will Deacon [off-list ref] wrote:
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a55b ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vincent Whitchurch <redacted>
Link: https://lore.kernel.org/linux-arm-kernel/1442944788-17254-1-git-send-email-rric@kernel.org/
Link: https://lore.kernel.org/linux-arm-kernel/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com/
Link: https://lore.kernel.org/linux-arm-kernel/20190614131141.4428-1-msys.mizuma@gmail.com/
Link: https://lore.kernel.org/r/20210517074332.28280-1-vincent.whitchurch@axis.com
Signed-off-by: Will Deacon <will@kernel.org>
On Fri, May 28, 2021 at 11:35:32AM +0200, Arnd Bergmann wrote:
On Thu, May 27, 2021 at 3:19 PM Mark Rutland [off-list ref] wrote:
quoted
quoted
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
The rationale above makes sense to me, so:
Acked-by: Mark Rutland <mark.rutland@arm.com>
I think it would make sense to go even further than this in the
future, and allow
setting a smaller minimum alignment depending what hardware is detected
at boot time.
Yeah, we talked about this in the past. The problem is that very early
the kernel doesn't know whether it'll have devices that require
non-coherent DMA. So we'd probably need to start with a 64 byte
ARCH_DMA_MINALIGN and populate the slab caches slightly later once the
kernel learns more about the system it's running on.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-06-01 18:24:01
On Thu, 27 May 2021 13:43:56 +0100, Will Deacon wrote:
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
[...]
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2021-06-02 13:27:47
Hi Will,
On 27.05.2021 14:43, Will Deacon wrote:
Back in 97303480753e ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b9839b, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0fa2
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a55b ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vincent Whitchurch <redacted>
Link: https://lore.kernel.org/linux-arm-kernel/1442944788-17254-1-git-send-email-rric@kernel.org/
Link: https://lore.kernel.org/linux-arm-kernel/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com/
Link: https://lore.kernel.org/linux-arm-kernel/20190614131141.4428-1-msys.mizuma@gmail.com/
Link: https://lore.kernel.org/r/20210517074332.28280-1-vincent.whitchurch@axis.com
Signed-off-by: Will Deacon <will@kernel.org>
---
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-02 13:53:13
Hi Marek,
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
Is your filesystem on the SD card, or some USB storage? I'm guessing
we'll need to stress DMA over one of those.
Thanks,
Mark.
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2021-06-02 14:11:34
Hi
On 02.06.2021 15:51, Mark Rutland wrote:
Hi Marek,
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
quoted
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
I'm booting the kernel with the mainline dtb
(arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb) from the u-boot,
which downloads it via TFTP. I don't remember which firmware version is
there, but without raspberry specific tools (which I don't have deployed
there) it is hard to check that now. The rootfs is on SD card, the
system is some older Debian release. Here is the last part of the boot
log if it helps:
[ 7.906329] Freeing unused kernel memory: 8512K
[ 7.911793] Run /sbin/init as init process
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
ERROR: could not open /proc/stat: No such file or directory
[....] Starting the hotplug events dispatcher: systemd-udevdstarting
version 236
. ok
[....] Synthesizing the initial hotplug events...[ 13.641287]
bcm2835-rng 3f104000.rng: hwrng registered
[ 13.896575] i2c-bcm2835 3f805000.i2c: Could not read clock-frequency
property
done.
[ 13.938691] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi'
already present!
[ 13.983716] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 13.991816] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[ 14.000945] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 14.009644] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
[ 14.017547] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 14.025780] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 14.033995] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 14.042196] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[....] Waiting for /dev to be fully populated...[ 14.112812] [drm]
Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
done.
[ ok ] Activating swap...done.
[....] Checking file systems...fsck from util-linux 2.29.2
done.
[ ok ] Cleaning up temporary files... /tmp.
[ ok ] Mounting local filesystems...done.
[ ok ] Activating swapfile swap...done.
[ ok ] Cleaning up temporary files....
[ ok ] Setting kernel variables...done.
[ ok ] Configuring network interfaces...done.
[ ok ] Starting RPC port mapper daemon: rpcbind.
[ ok ] Cleaning up temporary files....
[ ok ] Setting up ALSA...done.
[ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jun 2, 2021 at 3:51 PM Mark Rutland [off-list ref] wrote:
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
quoted
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
Is your filesystem on the SD card, or some USB storage? I'm guessing
we'll need to stress DMA over one of those.
It could be something other than DMA in this case, possibly an out-of-bounds
access into a dynamically allocated structure that happens to work when there
is extra data at the end of it. Running that kernel with KASAN should help
rule this out.
Running the same kernel on a Pi 4, or on a virtual machine could also help
figure out if there is something hardware specific.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2021-06-02 14:17:07
Hi Arnd,
On 02.06.2021 16:11, Arnd Bergmann wrote:
On Wed, Jun 2, 2021 at 3:51 PM Mark Rutland [off-list ref] wrote:
quoted
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
quoted
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
Is your filesystem on the SD card, or some USB storage? I'm guessing
we'll need to stress DMA over one of those.
It could be something other than DMA in this case, possibly an out-of-bounds
access into a dynamically allocated structure that happens to work when there
is extra data at the end of it. Running that kernel with KASAN should help
rule this out.
Okay, I will enable KASAN and give it a try.
Running the same kernel on a Pi 4, or on a virtual machine could also help
figure out if there is something hardware specific.
Exactly the same kernel binary boots fine on RPi4, virt (qemu) and a few
other arm64 boards I have on my test farm.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if the vc4's cache is involved here rather than the CPU cache.
If it's that, then removing the vc4 drivers should make it boot reliably, and
it might be possible to fix it by manually padding any allocations that get
passed to the GPU.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if the vc4's cache is involved here rather than the CPU cache.
If it's that, then removing the vc4 drivers should make it boot reliably, and
it might be possible to fix it by manually padding any allocations that get
passed to the GPU.
Indeed, after disabling DRM_VC4 in the .config, system boots fine and
seems to be working correctly.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if the vc4's cache is involved here rather than the CPU cache.
If it's that, then removing the vc4 drivers should make it boot reliably, and
it might be possible to fix it by manually padding any allocations that get
passed to the GPU.
Indeed, after disabling DRM_VC4 in the .config, system boots fine and
seems to be working correctly.
Ok, that helps. This means there is a good chance it would be one of these:
$ git grep k[cmz]alloc drivers/gpu/drm/vc4
drivers/gpu/drm/vc4/vc4_bo.c: new_list =
kmalloc_array(new_size, sizeof(struct list_head),
drivers/gpu/drm/vc4/vc4_bo.c: bo = kzalloc(sizeof(*bo), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_bo.c: vc4->bo_labels =
kcalloc(VC4_BO_TYPE_COUNT, sizeof(*vc4->bo_labels),
drivers/gpu/drm/vc4/vc4_crtc.c: flip_state =
kzalloc(sizeof(*flip_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_crtc.c: vc4_state =
kzalloc(sizeof(*vc4_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_crtc.c: vc4_crtc_state =
kzalloc(sizeof(*vc4_crtc_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_crtc.c: vc4_crtc = devm_kzalloc(dev,
sizeof(*vc4_crtc), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_debugfs.c: devm_kzalloc(dev->dev,
sizeof(*entry), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_dpi.c: dpi = devm_kzalloc(dev, sizeof(*dpi),
GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_dpi.c: vc4_dpi_encoder = devm_kzalloc(dev,
sizeof(*vc4_dpi_encoder),
drivers/gpu/drm/vc4/vc4_drv.c: vc4file = kzalloc(sizeof(*vc4file), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_dsi.c: dsi->clk_onecell = devm_kzalloc(dev,
drivers/gpu/drm/vc4/vc4_dsi.c: vc4_dsi_encoder = devm_kzalloc(dev,
sizeof(*vc4_dsi_encoder),
drivers/gpu/drm/vc4/vc4_dsi.c: dsi = devm_kzalloc(dev, sizeof(*dsi),
GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_gem.c: bo_state = kcalloc(state->bo_count,
sizeof(*bo_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_gem.c: kernel_state = kcalloc(1,
sizeof(*kernel_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_gem.c: kernel_state->bo = kcalloc(state->bo_count,
drivers/gpu/drm/vc4/vc4_gem.c: fence = kzalloc(sizeof(*fence), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_gem.c: exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_hdmi.c: kzalloc(sizeof(*new_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_hdmi.c: new_state =
kzalloc(sizeof(*new_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_hdmi.c: regs = kcalloc(variant->num_registers,
sizeof(*regs),
drivers/gpu/drm/vc4/vc4_hdmi.c: vc4_hdmi = devm_kzalloc(dev,
sizeof(*vc4_hdmi), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_hvs.c: hvs = devm_kzalloc(&pdev->dev,
sizeof(*hvs), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_kms.c: ctm_state =
kzalloc(sizeof(*ctm_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_kms.c: load_state =
kzalloc(sizeof(*load_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_kms.c: state = kzalloc(sizeof(*state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_kms.c: state = kzalloc(sizeof(*state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_perfmon.c: perfmon =
kzalloc(struct_size(perfmon, counters, req->ncounters),
drivers/gpu/drm/vc4/vc4_plane.c: vc4_state =
kzalloc(sizeof(*vc4_state), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_plane.c: u32 *new_dlist =
kmalloc_array(new_size, 4, GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_plane.c: vc4_plane =
devm_kzalloc(dev->dev, sizeof(*vc4_plane),
drivers/gpu/drm/vc4/vc4_txp.c: txp = devm_kzalloc(dev, sizeof(*txp),
GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_v3d.c: v3d = devm_kzalloc(&pdev->dev,
sizeof(*v3d), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_validate_shaders.c:
kcalloc(BITS_TO_LONGS(validation_state.max_ip),
drivers/gpu/drm/vc4/vc4_validate_shaders.c: validated_shader =
kcalloc(1, sizeof(*validated_shader), GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_vec.c: vec_connector = devm_kzalloc(dev->dev,
sizeof(*vec_connector),
drivers/gpu/drm/vc4/vc4_vec.c: vec = devm_kzalloc(dev, sizeof(*vec),
GFP_KERNEL);
drivers/gpu/drm/vc4/vc4_vec.c: vc4_vec_encoder = devm_kzalloc(dev,
sizeof(*vc4_vec_encoder),
I suppose most can be easily ruled out because they are not shared, or
because they are larger
than 64 bytes. I'll have a quick look if I find any smoking guns.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-04 10:03:18
Hi Marek,
On Wed, Jun 02, 2021 at 04:09:19PM +0200, Marek Szyprowski wrote:
On 02.06.2021 15:51, Mark Rutland wrote:
quoted
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
quoted
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
I'm booting the kernel with the mainline dtb
(arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb) from the u-boot,
which downloads it via TFTP. I don't remember which firmware version is
there, but without raspberry specific tools (which I don't have deployed
there) it is hard to check that now.
Thanks, this was enough info to get started.
For comparison, I have a 3Bv1.2 board.
I grabbed the latest RPI firmware, built myself a v2021.07-rc3
rpi_3_defconfig u-boot, and got a kernel booting (off the SD card rather
than over the network).
For the kernel I'm testing commit 65688d2a05de; defconfig with DRM and
VC4 built-in, since passing modules around is painful in my setup.
The rootfs is on SD card, the system is some older Debian release.
For comparison, I built myself a buildroot 2021.02.2 filesystem.
So far, booting up an running I'm not seeeing issues (and no complaints
from KASAN or similar), but I don't have a good way to stress the VC4
GPU, so I might not be triggering whatever's going wrong.
From the log below I see the last message is about X sockets -- is the
lockup happening when the display manager starts?
Thanks,
Mark.
Here is the last part of the boot
log if it helps:
[ 7.906329] Freeing unused kernel memory: 8512K
[ 7.911793] Run /sbin/init as init process
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
ERROR: could not open /proc/stat: No such file or directory
[....] Starting the hotplug events dispatcher: systemd-udevdstarting
version 236
. ok
[....] Synthesizing the initial hotplug events...[ 13.641287]
bcm2835-rng 3f104000.rng: hwrng registered
[ 13.896575] i2c-bcm2835 3f805000.i2c: Could not read clock-frequency
property
done.
[ 13.938691] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi'
already present!
[ 13.983716] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 13.991816] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[ 14.000945] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 14.009644] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
[ 14.017547] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 14.025780] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 14.033995] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 14.042196] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[....] Waiting for /dev to be fully populated...[ 14.112812] [drm]
Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
done.
[ ok ] Activating swap...done.
[....] Checking file systems...fsck from util-linux 2.29.2
done.
[ ok ] Cleaning up temporary files... /tmp.
[ ok ] Mounting local filesystems...done.
[ ok ] Activating swapfile swap...done.
[ ok ] Cleaning up temporary files....
[ ok ] Setting kernel variables...done.
[ ok ] Configuring network interfaces...done.
[ ok ] Starting RPC port mapper daemon: rpcbind.
[ ok ] Cleaning up temporary files....
[ ok ] Setting up ALSA...done.
[ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2021-06-07 10:36:33
Hi Mark,
On 04.06.2021 12:01, Mark Rutland wrote:
On Wed, Jun 02, 2021 at 04:09:19PM +0200, Marek Szyprowski wrote:
quoted
On 02.06.2021 15:51, Mark Rutland wrote:
quoted
On Wed, Jun 02, 2021 at 03:25:41PM +0200, Marek Szyprowski wrote:
quoted
On 27.05.2021 14:43, Will Deacon wrote:
This patch landed in todays linux-next as commit 65688d2a05de ("arm64:
cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)"). It causes an
issue on Raspberry Pi 3b board. System boots to userspace fine, but then
it hangs somewhere during the init scripts after loading the modules. I
didn't manage to track where it hangs yet though.
Ouch!
I have a 3b in a drawer that I might be able to reproduce the issue
with; can you tell me how you're booting that kernel? e.g. which FW and
DT you're using?
I'm booting the kernel with the mainline dtb
(arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb) from the u-boot,
which downloads it via TFTP. I don't remember which firmware version is
there, but without raspberry specific tools (which I don't have deployed
there) it is hard to check that now.
Thanks, this was enough info to get started.
For comparison, I have a 3Bv1.2 board.
I grabbed the latest RPI firmware, built myself a v2021.07-rc3
rpi_3_defconfig u-boot, and got a kernel booting (off the SD card rather
than over the network).
For the kernel I'm testing commit 65688d2a05de; defconfig with DRM and
VC4 built-in, since passing modules around is painful in my setup.
quoted
The rootfs is on SD card, the system is some older Debian release.
For comparison, I built myself a buildroot 2021.02.2 filesystem.
So far, booting up an running I'm not seeeing issues (and no complaints
from KASAN or similar), but I don't have a good way to stress the VC4
GPU, so I might not be triggering whatever's going wrong.
quoted
From the log below I see the last message is about X sockets -- is the
lockup happening when the display manager starts?
I've just checked with the latest firmware from
https://github.com/raspberrypi/firmware (master branch, just copied
everything to /boot) and the issue is still there.
If you start from arm64/defconfig without modules, please make sure you
have enabled all RPi drivers, otherwise VC4 DRM won't come up. I've
managed to reproduce the issue without the modules with the following
changes to arm64's defconfig:
./scripts/config -e DRM -e DRM_VC4 -e CONFIG_CLK_RASPBERRYPI -e
CONFIG_SENSORS_RASPBERRYPI_HWMON -e CONFIG_I2C_BCM2835 -e
CONFIG_ARM_RASPBERRYPI_CPUFREQ
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-07 12:03:15
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
Hi Mark,
I've just checked with the latest firmware from
https://github.com/raspberrypi/firmware (master branch, just copied
everything to /boot) and the issue is still there.
If you start from arm64/defconfig without modules, please make sure you
have enabled all RPi drivers, otherwise VC4 DRM won't come up. I've
managed to reproduce the issue without the modules with the following
changes to arm64's defconfig:
./scripts/config -e DRM -e DRM_VC4 -e CONFIG_CLK_RASPBERRYPI -e
CONFIG_SENSORS_RASPBERRYPI_HWMON -e CONFIG_I2C_BCM2835 -e
CONFIG_ARM_RASPBERRYPI_CPUFREQ
Thanks for this!
With that config on commit 65688d2a05deb9f0 I also see a hang at the end
of boot, but before reaching userspace, with the last messages in dmesg
as below.
I'll go check that the ARCH_DMA_MINALIGN affects this, then I'll go play
with debug options.
| [ 1.397102] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2
| [ 1.406437] serial serial0: tty port ttyAMA0 registered
| [ 1.408914] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
| [ 1.430510] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-05-24T19:52:58
| [ 1.504953] mmc0: host does not support reading read-only switch, assuming write-enable
| [ 1.514908] mmc0: new high speed SDXC card at address 0001
| [ 1.521626] mmcblk0: mmc0:0001 00000 59.6 GiB
| [ 1.528406] mmcblk0: p1 p2
| [ 1.644694] debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present!
| [ 1.654544] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
| [ 1.661078] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
| [ 1.667401] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
| [ 1.673760] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
| [ 1.680096] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
| [ 1.687157] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
| [ 1.694172] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
| [ 1.701170] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
| [ 1.709277] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jun 2, 2021 at 4:52 PM Arnd Bergmann [off-list ref] wrote:
On Wed, Jun 2, 2021 at 4:28 PM Marek Szyprowski [off-list ref] wrote:
I suppose most can be easily ruled out because they are not shared, or
because they are larger than 64 bytes. I'll have a quick look if I find any smoking guns.
Sorry for the late follow-up. I did check these last week, but
unfortunately none of
the allocations in the vc4 driver itself looked suspicious to me in
the end. It might
still be an indirect allocation though, where the vc4 driver calls
into a drivers/drm/
API or something else that allocates a small DMA buffer.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-07 13:11:29
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
Hi Mark,
quoted
I've just checked with the latest firmware from
https://github.com/raspberrypi/firmware (master branch, just copied
everything to /boot) and the issue is still there.
If you start from arm64/defconfig without modules, please make sure you
have enabled all RPi drivers, otherwise VC4 DRM won't come up. I've
managed to reproduce the issue without the modules with the following
changes to arm64's defconfig:
./scripts/config -e DRM -e DRM_VC4 -e CONFIG_CLK_RASPBERRYPI -e
CONFIG_SENSORS_RASPBERRYPI_HWMON -e CONFIG_I2C_BCM2835 -e
CONFIG_ARM_RASPBERRYPI_CPUFREQ
Thanks for this!
With that config on commit 65688d2a05deb9f0 I also see a hang at the end
of boot, but before reaching userspace, with the last messages in dmesg
as below.
I'll go check that the ARCH_DMA_MINALIGN affects this, then I'll go play
with debug options.
I can confirm that with the ARCH_DMA_MINALIGN change reverted, the hang
goes away. Running with that reverted andwith KASAN, I get the
slab-out-of-bounds splat below, which occurs at the time the hang would
otherwise occur, and is possibly the problem:
[ 3.609515] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 3.621451] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[ 3.628344] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 3.635904] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
[ 3.643351] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 3.651238] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 3.659167] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 3.666499] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[ 3.688560] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 3.728010] ==================================================================
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
[ 3.728153]
[ 3.728169] CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-00009-g694c523e7267 #3
[ 3.728203] Hardware name: Raspberry Pi 3 Model B (DT)
[ 3.728225] Workqueue: events_unbound deferred_probe_work_func
[ 3.728290] Call trace:
[ 3.728301] dump_backtrace+0x0/0x2b4
[ 3.728358] show_stack+0x1c/0x30
[ 3.728407] dump_stack+0xfc/0x168
[ 3.728445] print_address_description.constprop.0+0x2c/0x2c0
[ 3.728495] kasan_report+0x1dc/0x240
[ 3.728529] __asan_load8+0x98/0xd4
[ 3.728565] vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728621] commit_tail+0x100/0x210
[ 3.728675] drm_atomic_helper_commit+0x1c4/0x3dc
[ 3.728730] drm_atomic_commit+0x80/0x94
[ 3.728768] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.728821] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.728872] drm_fb_helper_pan_display+0x164/0x3a0
[ 3.728924] fb_pan_display+0x12c/0x1fc
[ 3.728963] bit_update_start+0x34/0xa0
[ 3.729013] fbcon_switch+0x678/0x920
[ 3.729058] redraw_screen+0x17c/0x35c
[ 3.729095] fbcon_prepare_logo+0x484/0x5bc
[ 3.729143] fbcon_init+0x77c/0x970
[ 3.729187] visual_init+0x14c/0x1e4
[ 3.729239] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.729279] do_take_over_console+0x200/0x2e0
[ 3.729317] do_fbcon_takeover+0x90/0x120
[ 3.729363] fbcon_fb_registered+0x14c/0x164
[ 3.729412] register_framebuffer+0x308/0x4e0
[ 3.729451] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.729506] drm_fbdev_client_hotplug+0x204/0x374
[ 3.729556] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.729604] vc4_drm_bind+0x1d4/0x1f0
[ 3.729654] try_to_bring_up_master+0x254/0x2dc
[ 3.729709] __component_add+0x10c/0x240
[ 3.729759] component_add+0x18/0x24
[ 3.729807] vc4_v3d_dev_probe+0x20/0x30
[ 3.729854] platform_probe+0x90/0x110
[ 3.729907] really_probe+0x148/0x744
[ 3.729952] driver_probe_device+0x8c/0xfc
[ 3.729998] __device_attach_driver+0x120/0x180
[ 3.730048] bus_for_each_drv+0xf4/0x15c
[ 3.730091] __device_attach+0x168/0x250
[ 3.730137] device_initial_probe+0x18/0x24
[ 3.730186] bus_probe_device+0xec/0x100
[ 3.730230] deferred_probe_work_func+0xe8/0x130
[ 3.730279] process_one_work+0x3b8/0x650
[ 3.730319] worker_thread+0x3cc/0x72c
[ 3.730356] kthread+0x21c/0x224
[ 3.730402] ret_from_fork+0x10/0x38
[ 3.730442]
[ 3.730453] Allocated by task 7:
[ 3.730470] kasan_save_stack+0x2c/0x60
[ 3.730526] __kasan_kmalloc+0x90/0xb4
[ 3.730577] vc4_hvs_channels_duplicate_state+0x60/0x1a0
[ 3.730637] drm_atomic_get_private_obj_state+0x144/0x230
[ 3.730680] vc4_atomic_check+0x40/0x73c
[ 3.730732] drm_atomic_check_only+0x998/0xe60
[ 3.730769] drm_atomic_commit+0x34/0x94
[ 3.730804] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.730854] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.730904] drm_client_modeset_commit+0x38/0x60
[ 3.730951] drm_fb_helper_set_par+0x104/0x17c
[ 3.730998] fbcon_init+0x43c/0x970
[ 3.731041] visual_init+0x14c/0x1e4
[ 3.731090] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.731128] do_take_over_console+0x200/0x2e0
[ 3.731165] do_fbcon_takeover+0x90/0x120
[ 3.731210] fbcon_fb_registered+0x14c/0x164
[ 3.731258] register_framebuffer+0x308/0x4e0
[ 3.731296] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.731349] drm_fbdev_client_hotplug+0x204/0x374
[ 3.731398] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.731446] vc4_drm_bind+0x1d4/0x1f0
[ 3.731493] try_to_bring_up_master+0x254/0x2dc
[ 3.731546] __component_add+0x10c/0x240
[ 3.731594] component_add+0x18/0x24
[ 3.731642] vc4_v3d_dev_probe+0x20/0x30
[ 3.731686] platform_probe+0x90/0x110
[ 3.731737] really_probe+0x148/0x744
[ 3.731781] driver_probe_device+0x8c/0xfc
[ 3.731827] __device_attach_driver+0x120/0x180
[ 3.731875] bus_for_each_drv+0xf4/0x15c
[ 3.731916] __device_attach+0x168/0x250
[ 3.731962] device_initial_probe+0x18/0x24
[ 3.732009] bus_probe_device+0xec/0x100
[ 3.732052] deferred_probe_work_func+0xe8/0x130
[ 3.732100] process_one_work+0x3b8/0x650
[ 3.732137] worker_thread+0x3cc/0x72c
[ 3.732172] kthread+0x21c/0x224
[ 3.732215] ret_from_fork+0x10/0x38
[ 3.732253]
[ 3.732262] The buggy address belongs to the object at ffff000007360400
[ 3.732262] which belongs to the cache kmalloc-128 of size 128
[ 3.732293] The buggy address is located 64 bytes inside of
[ 3.732293] 128-byte region [ffff000007360400, ffff000007360480)
[ 3.732329] The buggy address belongs to the page:
[ 3.732344] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7360
[ 3.732380] flags: 0x3fffc0000000200(slab|node=0|zone=0|lastcpupid=0xffff)
[ 3.732442] raw: 03fffc0000000200 dead000000000100 dead000000000122 ffff000004c02300
[ 3.732478] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[ 3.732501] page dumped because: kasan: bad access detected
[ 3.732518]
[ 3.732527] Memory state around the buggy address:
[ 3.732549] ffff000007360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732579] ffff000007360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732608] >ffff000007360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
[ 3.732629] ^
[ 3.732652] ffff000007360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732682] ffff000007360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732703] ==================================================================
[ 3.732718] Disabling lock debugging due to kernel taint
[ 3.769129] Console: switching to colour frame buffer device 90x30
[ 5.148699] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-06-07 13:44:05
[Adding VC4 folks -- please see the KASAN splat below!]
Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
-next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
Will
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
I've just checked with the latest firmware from
https://github.com/raspberrypi/firmware (master branch, just copied
everything to /boot) and the issue is still there.
If you start from arm64/defconfig without modules, please make sure you
have enabled all RPi drivers, otherwise VC4 DRM won't come up. I've
managed to reproduce the issue without the modules with the following
changes to arm64's defconfig:
./scripts/config -e DRM -e DRM_VC4 -e CONFIG_CLK_RASPBERRYPI -e
CONFIG_SENSORS_RASPBERRYPI_HWMON -e CONFIG_I2C_BCM2835 -e
CONFIG_ARM_RASPBERRYPI_CPUFREQ
Thanks for this!
With that config on commit 65688d2a05deb9f0 I also see a hang at the end
of boot, but before reaching userspace, with the last messages in dmesg
as below.
I'll go check that the ARCH_DMA_MINALIGN affects this, then I'll go play
with debug options.
I can confirm that with the ARCH_DMA_MINALIGN change reverted, the hang
goes away. Running with that reverted andwith KASAN, I get the
slab-out-of-bounds splat below, which occurs at the time the hang would
otherwise occur, and is possibly the problem:
[ 3.609515] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 3.621451] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[ 3.628344] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 3.635904] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
[ 3.643351] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 3.651238] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 3.659167] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 3.666499] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[ 3.688560] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 3.728010] ==================================================================
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
[ 3.728153]
[ 3.728169] CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-00009-g694c523e7267 #3
[ 3.728203] Hardware name: Raspberry Pi 3 Model B (DT)
[ 3.728225] Workqueue: events_unbound deferred_probe_work_func
[ 3.728290] Call trace:
[ 3.728301] dump_backtrace+0x0/0x2b4
[ 3.728358] show_stack+0x1c/0x30
[ 3.728407] dump_stack+0xfc/0x168
[ 3.728445] print_address_description.constprop.0+0x2c/0x2c0
[ 3.728495] kasan_report+0x1dc/0x240
[ 3.728529] __asan_load8+0x98/0xd4
[ 3.728565] vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728621] commit_tail+0x100/0x210
[ 3.728675] drm_atomic_helper_commit+0x1c4/0x3dc
[ 3.728730] drm_atomic_commit+0x80/0x94
[ 3.728768] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.728821] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.728872] drm_fb_helper_pan_display+0x164/0x3a0
[ 3.728924] fb_pan_display+0x12c/0x1fc
[ 3.728963] bit_update_start+0x34/0xa0
[ 3.729013] fbcon_switch+0x678/0x920
[ 3.729058] redraw_screen+0x17c/0x35c
[ 3.729095] fbcon_prepare_logo+0x484/0x5bc
[ 3.729143] fbcon_init+0x77c/0x970
[ 3.729187] visual_init+0x14c/0x1e4
[ 3.729239] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.729279] do_take_over_console+0x200/0x2e0
[ 3.729317] do_fbcon_takeover+0x90/0x120
[ 3.729363] fbcon_fb_registered+0x14c/0x164
[ 3.729412] register_framebuffer+0x308/0x4e0
[ 3.729451] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.729506] drm_fbdev_client_hotplug+0x204/0x374
[ 3.729556] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.729604] vc4_drm_bind+0x1d4/0x1f0
[ 3.729654] try_to_bring_up_master+0x254/0x2dc
[ 3.729709] __component_add+0x10c/0x240
[ 3.729759] component_add+0x18/0x24
[ 3.729807] vc4_v3d_dev_probe+0x20/0x30
[ 3.729854] platform_probe+0x90/0x110
[ 3.729907] really_probe+0x148/0x744
[ 3.729952] driver_probe_device+0x8c/0xfc
[ 3.729998] __device_attach_driver+0x120/0x180
[ 3.730048] bus_for_each_drv+0xf4/0x15c
[ 3.730091] __device_attach+0x168/0x250
[ 3.730137] device_initial_probe+0x18/0x24
[ 3.730186] bus_probe_device+0xec/0x100
[ 3.730230] deferred_probe_work_func+0xe8/0x130
[ 3.730279] process_one_work+0x3b8/0x650
[ 3.730319] worker_thread+0x3cc/0x72c
[ 3.730356] kthread+0x21c/0x224
[ 3.730402] ret_from_fork+0x10/0x38
[ 3.730442]
[ 3.730453] Allocated by task 7:
[ 3.730470] kasan_save_stack+0x2c/0x60
[ 3.730526] __kasan_kmalloc+0x90/0xb4
[ 3.730577] vc4_hvs_channels_duplicate_state+0x60/0x1a0
[ 3.730637] drm_atomic_get_private_obj_state+0x144/0x230
[ 3.730680] vc4_atomic_check+0x40/0x73c
[ 3.730732] drm_atomic_check_only+0x998/0xe60
[ 3.730769] drm_atomic_commit+0x34/0x94
[ 3.730804] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.730854] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.730904] drm_client_modeset_commit+0x38/0x60
[ 3.730951] drm_fb_helper_set_par+0x104/0x17c
[ 3.730998] fbcon_init+0x43c/0x970
[ 3.731041] visual_init+0x14c/0x1e4
[ 3.731090] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.731128] do_take_over_console+0x200/0x2e0
[ 3.731165] do_fbcon_takeover+0x90/0x120
[ 3.731210] fbcon_fb_registered+0x14c/0x164
[ 3.731258] register_framebuffer+0x308/0x4e0
[ 3.731296] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.731349] drm_fbdev_client_hotplug+0x204/0x374
[ 3.731398] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.731446] vc4_drm_bind+0x1d4/0x1f0
[ 3.731493] try_to_bring_up_master+0x254/0x2dc
[ 3.731546] __component_add+0x10c/0x240
[ 3.731594] component_add+0x18/0x24
[ 3.731642] vc4_v3d_dev_probe+0x20/0x30
[ 3.731686] platform_probe+0x90/0x110
[ 3.731737] really_probe+0x148/0x744
[ 3.731781] driver_probe_device+0x8c/0xfc
[ 3.731827] __device_attach_driver+0x120/0x180
[ 3.731875] bus_for_each_drv+0xf4/0x15c
[ 3.731916] __device_attach+0x168/0x250
[ 3.731962] device_initial_probe+0x18/0x24
[ 3.732009] bus_probe_device+0xec/0x100
[ 3.732052] deferred_probe_work_func+0xe8/0x130
[ 3.732100] process_one_work+0x3b8/0x650
[ 3.732137] worker_thread+0x3cc/0x72c
[ 3.732172] kthread+0x21c/0x224
[ 3.732215] ret_from_fork+0x10/0x38
[ 3.732253]
[ 3.732262] The buggy address belongs to the object at ffff000007360400
[ 3.732262] which belongs to the cache kmalloc-128 of size 128
[ 3.732293] The buggy address is located 64 bytes inside of
[ 3.732293] 128-byte region [ffff000007360400, ffff000007360480)
[ 3.732329] The buggy address belongs to the page:
[ 3.732344] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7360
[ 3.732380] flags: 0x3fffc0000000200(slab|node=0|zone=0|lastcpupid=0xffff)
[ 3.732442] raw: 03fffc0000000200 dead000000000100 dead000000000122 ffff000004c02300
[ 3.732478] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[ 3.732501] page dumped because: kasan: bad access detected
[ 3.732518]
[ 3.732527] Memory state around the buggy address:
[ 3.732549] ffff000007360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732579] ffff000007360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732608] >ffff000007360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
[ 3.732629] ^
[ 3.732652] ffff000007360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732682] ffff000007360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732703] ==================================================================
[ 3.732718] Disabling lock debugging due to kernel taint
[ 3.769129] Console: switching to colour frame buffer device 90x30
[ 5.148699] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-07 13:58:40
On Mon, Jun 07, 2021 at 02:39:54PM +0100, Will Deacon wrote:
[Adding VC4 folks -- please see the KASAN splat below!]
Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
-next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
Will
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
I've just checked with the latest firmware from
https://github.com/raspberrypi/firmware (master branch, just copied
everything to /boot) and the issue is still there.
If you start from arm64/defconfig without modules, please make sure you
have enabled all RPi drivers, otherwise VC4 DRM won't come up. I've
managed to reproduce the issue without the modules with the following
changes to arm64's defconfig:
./scripts/config -e DRM -e DRM_VC4 -e CONFIG_CLK_RASPBERRYPI -e
CONFIG_SENSORS_RASPBERRYPI_HWMON -e CONFIG_I2C_BCM2835 -e
CONFIG_ARM_RASPBERRYPI_CPUFREQ
Thanks for this!
With that config on commit 65688d2a05deb9f0 I also see a hang at the end
of boot, but before reaching userspace, with the last messages in dmesg
as below.
I'll go check that the ARCH_DMA_MINALIGN affects this, then I'll go play
with debug options.
I can confirm that with the ARCH_DMA_MINALIGN change reverted, the hang
goes away. Running with that reverted andwith KASAN, I get the
slab-out-of-bounds splat below, which occurs at the time the hang would
otherwise occur, and is possibly the problem:
[ 3.609515] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[ 3.621451] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[ 3.628344] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[ 3.635904] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
[ 3.643351] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[ 3.651238] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[ 3.659167] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[ 3.666499] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)
[ 3.688560] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 3.728010] ==================================================================
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
FWIW, faddr2line tells me this is:
[mark@lakrids:~/src/linux]% ./scripts/faddr2line vmlinux vc4_atomic_commit_tail+0x1cc/0x910
vc4_atomic_commit_tail+0x1cc/0x910:
vc4_atomic_commit_tail at drivers/gpu/drm/vc4/vc4_kms.c:375
... which is:
| ret = drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit);
Thanks,
Mark.
quoted
[ 3.728153]
[ 3.728169] CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-00009-g694c523e7267 #3
[ 3.728203] Hardware name: Raspberry Pi 3 Model B (DT)
[ 3.728225] Workqueue: events_unbound deferred_probe_work_func
[ 3.728290] Call trace:
[ 3.728301] dump_backtrace+0x0/0x2b4
[ 3.728358] show_stack+0x1c/0x30
[ 3.728407] dump_stack+0xfc/0x168
[ 3.728445] print_address_description.constprop.0+0x2c/0x2c0
[ 3.728495] kasan_report+0x1dc/0x240
[ 3.728529] __asan_load8+0x98/0xd4
[ 3.728565] vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728621] commit_tail+0x100/0x210
[ 3.728675] drm_atomic_helper_commit+0x1c4/0x3dc
[ 3.728730] drm_atomic_commit+0x80/0x94
[ 3.728768] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.728821] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.728872] drm_fb_helper_pan_display+0x164/0x3a0
[ 3.728924] fb_pan_display+0x12c/0x1fc
[ 3.728963] bit_update_start+0x34/0xa0
[ 3.729013] fbcon_switch+0x678/0x920
[ 3.729058] redraw_screen+0x17c/0x35c
[ 3.729095] fbcon_prepare_logo+0x484/0x5bc
[ 3.729143] fbcon_init+0x77c/0x970
[ 3.729187] visual_init+0x14c/0x1e4
[ 3.729239] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.729279] do_take_over_console+0x200/0x2e0
[ 3.729317] do_fbcon_takeover+0x90/0x120
[ 3.729363] fbcon_fb_registered+0x14c/0x164
[ 3.729412] register_framebuffer+0x308/0x4e0
[ 3.729451] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.729506] drm_fbdev_client_hotplug+0x204/0x374
[ 3.729556] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.729604] vc4_drm_bind+0x1d4/0x1f0
[ 3.729654] try_to_bring_up_master+0x254/0x2dc
[ 3.729709] __component_add+0x10c/0x240
[ 3.729759] component_add+0x18/0x24
[ 3.729807] vc4_v3d_dev_probe+0x20/0x30
[ 3.729854] platform_probe+0x90/0x110
[ 3.729907] really_probe+0x148/0x744
[ 3.729952] driver_probe_device+0x8c/0xfc
[ 3.729998] __device_attach_driver+0x120/0x180
[ 3.730048] bus_for_each_drv+0xf4/0x15c
[ 3.730091] __device_attach+0x168/0x250
[ 3.730137] device_initial_probe+0x18/0x24
[ 3.730186] bus_probe_device+0xec/0x100
[ 3.730230] deferred_probe_work_func+0xe8/0x130
[ 3.730279] process_one_work+0x3b8/0x650
[ 3.730319] worker_thread+0x3cc/0x72c
[ 3.730356] kthread+0x21c/0x224
[ 3.730402] ret_from_fork+0x10/0x38
[ 3.730442]
[ 3.730453] Allocated by task 7:
[ 3.730470] kasan_save_stack+0x2c/0x60
[ 3.730526] __kasan_kmalloc+0x90/0xb4
[ 3.730577] vc4_hvs_channels_duplicate_state+0x60/0x1a0
[ 3.730637] drm_atomic_get_private_obj_state+0x144/0x230
[ 3.730680] vc4_atomic_check+0x40/0x73c
[ 3.730732] drm_atomic_check_only+0x998/0xe60
[ 3.730769] drm_atomic_commit+0x34/0x94
[ 3.730804] drm_client_modeset_commit_atomic+0x2f4/0x3a0
[ 3.730854] drm_client_modeset_commit_locked+0x8c/0x230
[ 3.730904] drm_client_modeset_commit+0x38/0x60
[ 3.730951] drm_fb_helper_set_par+0x104/0x17c
[ 3.730998] fbcon_init+0x43c/0x970
[ 3.731041] visual_init+0x14c/0x1e4
[ 3.731090] do_bind_con_driver.isra.0+0x2c4/0x530
[ 3.731128] do_take_over_console+0x200/0x2e0
[ 3.731165] do_fbcon_takeover+0x90/0x120
[ 3.731210] fbcon_fb_registered+0x14c/0x164
[ 3.731258] register_framebuffer+0x308/0x4e0
[ 3.731296] __drm_fb_helper_initial_config_and_unlock+0x538/0x7d0
[ 3.731349] drm_fbdev_client_hotplug+0x204/0x374
[ 3.731398] drm_fbdev_generic_setup+0xf4/0x24c
[ 3.731446] vc4_drm_bind+0x1d4/0x1f0
[ 3.731493] try_to_bring_up_master+0x254/0x2dc
[ 3.731546] __component_add+0x10c/0x240
[ 3.731594] component_add+0x18/0x24
[ 3.731642] vc4_v3d_dev_probe+0x20/0x30
[ 3.731686] platform_probe+0x90/0x110
[ 3.731737] really_probe+0x148/0x744
[ 3.731781] driver_probe_device+0x8c/0xfc
[ 3.731827] __device_attach_driver+0x120/0x180
[ 3.731875] bus_for_each_drv+0xf4/0x15c
[ 3.731916] __device_attach+0x168/0x250
[ 3.731962] device_initial_probe+0x18/0x24
[ 3.732009] bus_probe_device+0xec/0x100
[ 3.732052] deferred_probe_work_func+0xe8/0x130
[ 3.732100] process_one_work+0x3b8/0x650
[ 3.732137] worker_thread+0x3cc/0x72c
[ 3.732172] kthread+0x21c/0x224
[ 3.732215] ret_from_fork+0x10/0x38
[ 3.732253]
[ 3.732262] The buggy address belongs to the object at ffff000007360400
[ 3.732262] which belongs to the cache kmalloc-128 of size 128
[ 3.732293] The buggy address is located 64 bytes inside of
[ 3.732293] 128-byte region [ffff000007360400, ffff000007360480)
[ 3.732329] The buggy address belongs to the page:
[ 3.732344] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7360
[ 3.732380] flags: 0x3fffc0000000200(slab|node=0|zone=0|lastcpupid=0xffff)
[ 3.732442] raw: 03fffc0000000200 dead000000000100 dead000000000122 ffff000004c02300
[ 3.732478] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
[ 3.732501] page dumped because: kasan: bad access detected
[ 3.732518]
[ 3.732527] Memory state around the buggy address:
[ 3.732549] ffff000007360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732579] ffff000007360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732608] >ffff000007360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
[ 3.732629] ^
[ 3.732652] ffff000007360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.732682] ffff000007360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.732703] ==================================================================
[ 3.732718] Disabling lock debugging due to kernel taint
[ 3.769129] Console: switching to colour frame buffer device 90x30
[ 5.148699] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon [off-list ref] wrote:
[Adding VC4 folks -- please see the KASAN splat below!]
Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
-next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
The great news for the patch that caused it is that this has nothing to
do with DMA alignment.
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
This is offset 0x40 into struct vc4_hvs_state, which is the
'pending_commit' pointer
for the array index 4, i.e. one after the end of the structure.
It seems to be this loop:
for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
struct vc4_crtc_state *vc4_crtc_state =
to_vc4_crtc_state(old_crtc_state);
unsigned int channel = vc4_crtc_state->assigned_channel;
int ret;
if (channel == VC4_HVS_CHANNEL_DISABLED)
continue;
if (!old_hvs_state->fifo_state[channel].in_use)
continue;
ret =
drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit);
if (ret)
drm_err(dev, "Timed out waiting for commit\n");
}
I notice that it checks index 'fifos_state[channel].in_use', but then
uses a different index 'i' for looking at the 'pending_commit' field
beyond the end of the array.
This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
("drm/vc4: kms: Wait on previous FIFO users before a commit").
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Maxime Ripard <hidden> Date: 2021-06-07 15:19:52
On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon [off-list ref] wrote:
quoted
[Adding VC4 folks -- please see the KASAN splat below!]
Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
-next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
The great news for the patch that caused it is that this has nothing to
do with DMA alignment.
quoted
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
quoted
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
This is offset 0x40 into struct vc4_hvs_state, which is the
'pending_commit' pointer
for the array index 4, i.e. one after the end of the structure.
It seems to be this loop:
for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
struct vc4_crtc_state *vc4_crtc_state =
to_vc4_crtc_state(old_crtc_state);
unsigned int channel = vc4_crtc_state->assigned_channel;
int ret;
if (channel == VC4_HVS_CHANNEL_DISABLED)
continue;
if (!old_hvs_state->fifo_state[channel].in_use)
continue;
ret =
drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit);
if (ret)
drm_err(dev, "Timed out waiting for commit\n");
}
I notice that it checks index 'fifos_state[channel].in_use', but then
uses a different index 'i' for looking at the 'pending_commit' field
beyond the end of the array.
This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
("drm/vc4: kms: Wait on previous FIFO users before a commit").
Awesome, I tried to find out that bug a few weeks ago but couldn't
reproduce the KASAN spat. You're right, it should be channel here
instead of i. Since you did the whole work, do you want to send the
patch?
maxime
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-07 15:34:54
On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon [off-list ref] wrote:
quoted
[Adding VC4 folks -- please see the KASAN splat below!]
Background here is that reducing ARCH_DMA_MINALIGN to 64 on arm64 (queued in
-next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
The great news for the patch that caused it is that this has nothing to
do with DMA alignment.
quoted
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
quoted
quoted
[ 3.728042] BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910
[ 3.728123] Read of size 8 at addr ffff000007360440 by task kworker/u8:0/7
This is offset 0x40 into struct vc4_hvs_state, which is the
'pending_commit' pointer
for the array index 4, i.e. one after the end of the structure.
It seems to be this loop:
for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
struct vc4_crtc_state *vc4_crtc_state =
to_vc4_crtc_state(old_crtc_state);
unsigned int channel = vc4_crtc_state->assigned_channel;
int ret;
if (channel == VC4_HVS_CHANNEL_DISABLED)
continue;
if (!old_hvs_state->fifo_state[channel].in_use)
continue;
ret =
drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit);
if (ret)
drm_err(dev, "Timed out waiting for commit\n");
}
I notice that it checks index 'fifos_state[channel].in_use', but then
uses a different index 'i' for looking at the 'pending_commit' field
beyond the end of the array.
FWIW, with that drm_crtc_commit_wait() call changed to:
| ret = drm_crtc_commit_wait(old_hvs_state->fifo_state[channel].pending_commit);
... I no longer see a KASAN splat, and I no longer see a hang with
ARCH_DMA_MINALIGN reduced to 64.
Thanks,
Mark.
This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
("drm/vc4: kms: Wait on previous FIFO users before a commit").
Arnd
On Mon, Jun 7, 2021 at 5:17 PM Maxime Ripard [off-list ref] wrote:
On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
quoted
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon [off-list ref] wrote:
quoted
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
I notice that it checks index 'fifos_state[channel].in_use', but then
uses a different index 'i' for looking at the 'pending_commit' field
beyond the end of the array.
This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
("drm/vc4: kms: Wait on previous FIFO users before a commit").
Awesome, I tried to find out that bug a few weeks ago but couldn't
reproduce the KASAN spat. You're right, it should be channel here
instead of i. Since you did the whole work, do you want to send the
patch?
Marek and Mark did most of the work finding the problem, I just looked
in the right place a few times (and a bit in the wrong place). I'd suggest
you send that patch with the corresponding Reported-by/Analyzed-by/
Tested-by tags.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-06-08 08:58:42
On Mon, Jun 07, 2021 at 05:50:57PM +0200, Arnd Bergmann wrote:
On Mon, Jun 7, 2021 at 5:17 PM Maxime Ripard [off-list ref] wrote:
quoted
On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
quoted
On Mon, Jun 7, 2021 at 3:39 PM Will Deacon [off-list ref] wrote:
quoted
On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
quoted
On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
I notice that it checks index 'fifos_state[channel].in_use', but then
uses a different index 'i' for looking at the 'pending_commit' field
beyond the end of the array.
This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
("drm/vc4: kms: Wait on previous FIFO users before a commit").
Awesome, I tried to find out that bug a few weeks ago but couldn't
reproduce the KASAN spat. You're right, it should be channel here
instead of i. Since you did the whole work, do you want to send the
patch?
Marek and Mark did most of the work finding the problem, I just looked
in the right place a few times (and a bit in the wrong place). I'd suggest
you send that patch with the corresponding Reported-by/Analyzed-by/
Tested-by tags.