linux-kernel - Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb

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: <CAA5qM4B1R4cA6=sDhWaVo59A=0WWR_wv5Ckp1O8giv7+pUuqRQ@mail.gmail.com>
Date:   Wed, 24 Feb 2021 07:24:40 -0500
From:   Tong Zhang <ztong0001@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync

Hi Geert,
IMHO - QEMU is irrelevant here. since I can do passthrough --
in fact -- many drivers do use timeout in .fb_sync
e.g. i810fb_sync(), nouveau_fbcon_sync(), sm501fb_sync() etc..
I believe the correct behaviour should be a timeout wait instead of
waiting indefinitely.
- Tong

On Wed, Feb 24, 2021 at 6:35 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Tong,
>
> On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <ztong0001@...il.com> wrote:
> > On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> > > On 2/20/21 3:02 PM, Tong Zhang wrote:
> > > > pm2fb_sync is called when doing /dev/fb read or write.
> > > > The original pm2fb_sync wait indefinitely on hardware flags which can
> > > > possibly stall kernel and make everything unresponsive.
> > > > Instead of waiting indefinitely, we can timeout to give user a chance to
> > > > get back control.
> > >
> > > Is this a real problem or theoretical?
> > > Does someone still use this driver?
> >
> > I currently have this problem on my machine.
> > I have submitted a revised patch -- which includes the console log.
>
> Your machine is "QEMU Standard"?
> Can this happen on real hardware, too, or is this a deficiency in QEMU,
> which should be fixed there?
>
> 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