linux-kernel - Re: fbdev deferred I/O broken in some scenarios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdVHpzQ8UcnJ_zxMnc7uDJPU-cybqo76ZUabqNBPcrY3nw@mail.gmail.com>
Date: Mon, 24 Mar 2025 14:59:52 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Michael Kelley <mhklinux@...look.com>
Cc: Helge Deller <deller@....de>, 
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>
Subject: Re: fbdev deferred I/O broken in some scenarios

Hi Michael,

On Thu, 20 Mar 2025 at 21:15, Michael Kelley <mhklinux@...look.com> wrote:
> From: Geert Uytterhoeven <geert@...ux-m68k.org> Sent: Thursday, March 20, 2025 3:46 AM
> > On Wed, 19 Mar 2025 at 21:29, Michael Kelley <mhklinux@...look.com> wrote:
> > > From: Helge Deller <deller@....de> Sent: Tuesday, March 18, 2025 1:16 AM
> > > > On 3/18/25 03:05, Michael Kelley wrote:
> > > > > The fbdev deferred I/O support was originally added to the hyperv_fb driver in the
> > > > > 5.6 kernel, and based on my recent experiments, it has never worked correctly when
> > > > > the framebuffer is allocated from kernel memory. fbdev deferred I/O support for using
> > > > > kernel memory as the framebuffer was originally added in commit 37b4837959cb9
> > > > > back in 2008 in Linux 2.6.29. But I don't see how it ever worked properly, unless
> > > > > changes in generic memory management somehow broke it in the intervening years.
> > > > >
> > > > > I think I know how to fix all this. But before working on a patch, I wanted to check
> > > > > with the fbdev community to see if this might be a known issue and whether there
> > > > > is any additional insight someone might offer. Thanks for any comments or help.
> > > >
> > > > I haven't heard of any major deferred-i/o issues since I've jumped into fbdev
> > > > maintenance. But you might be right, as I haven't looked much into it yet and
> > > > there are just a few drivers using it.
> > >
> > > Thanks for the input. In the fbdev directory, there are 9 drivers using deferred I/O.
> > > Of those, 6 use vmalloc() to allocate the framebuffer, and that path works just fine.
> > > The other 3 use alloc_pages(), dma_alloc_coherent(), or __get_free_pages(), all of
> > > which manifest the underlying problem when munmap()'ed.  Those 3 drivers are:
> > >
> > > * hyperv_fb.c, which I'm working with
> > > * sh_mobile_lcdcfb.c
> > > * ssd1307fb.c
> >
> > Nowadays sh_mobile_lcdcfb is used only on various SuperH boards
> > (I have no hardware to test).
> >
> > sh_mobile_lcdcfb was used on ARM-based SH/R-Mobile SoCs until DT
> > support was added to the DRM driver for the corresponding hardware.
> > The platform using it was migrated to DRM in commit 138588e9fa237f97
> > ("ARM: dts: renesas: r8a7740: Add LCDC nodes") in v6.8). At the time
> > of the conversion, fbtest worked fine with sh_mobile_lcdcfb.
>
> OK, good to know. sh_mobile_lcdcfb gets its framebuffer using
> dma_alloc_coherent(). Do you recall how big the framebuffer was?
> If over 4 MiB, dma_alloc_coherent() would have allocated from CMA,
> and that works OK.

1536000 bytes (800x480 (960 virtual), 16bpp), i.e. less than 4 MiB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds