fbdev mmap regression since 'Merge v6.10-rc6 into drm-next'

[Alexander Stein]

Hello,

I noticed that on linux-next one platform (TQMa6S imx6qdl-mba6.dtsi, using
i.MX6 Solo) I'm hitting SIGBUS errors when using fb-test on /dev/fb0.
strace shows:
> openat(AT_FDCWD, "/dev/fb0", O_RDWR|O_LARGEFILE) = 4
> ioctl(4, FBIOGET_VSCREENINFO, 0x4cb818) = 0
> ioctl(4, FBIOGET_FSCREENINFO, 0x4cb8b8) = 0
> write(1, "fb res 1920x1080 virtual 1920x10"..., 58fb res 1920x1080 virtual
> 1920x1080, line_len 3840, bpp 16 ) = 58
> mmap2(NULL, 4147200, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb6a94000
> --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0xb6a94000} ---
> +++ killed by SIGBUS (core dumped) +++

Using weston instead of fb-test works without issues.

I was able to track it down to commit 86634fa4e6aef ("Merge v6.10-rc6
into drm-next"). Unfortunately this is a merge and *both* bases are okay.

A requirement for this bug to trigger is having CMA area in Normal zone.
This automatically happens on systems with 512MiB RAM only:
> cma: Reserved 64 MiB at 0x2a800000 on node -1
> 
> Zone ranges:
>   Normal   [mem 0x0000000010000000-0x000000002fffffff]
>   HighMem  empty

On different modules providing 1GiB RAM there is also a HighMem zone available
which is used by default for CMA, unless the allocation explicitly specified.
In this case mmap works as expected. But even on modules having HighMem mmap
does not work when CMA is specified in Normal zone, refer to [1]. 

Despite the bisect I also tried the following commits directly, which
introduced the changes affecting the merge:
* d92a7580392ad ("drm/fbdev-dma: Only set smem_start is enable per module option")
* 808a40b694680 ("drm/fbdev-dma: Implement damage handling and deferred I/O")

But these commits by itself work as before. Cherry-picking d92a7580392ad on
top of 808a40b694680 already triggers the problem.
CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is unset, so I think commit d92a7580392ad
("drm/fbdev-dma: Only set smem_start is enable per module option") is
the culprit here.

How can this be fixed?

Best regards,
Alexander

[1] https://lore.kernel.org/all/20240827142458.265558-1-alexander.stein@ew.tq-group.com/
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/