linux-kernel - Re: [PATCH v3 0/5] Fix some race conditions that exists between fbmem and sysfb

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YmLHHCQyN03oAqr0@kroah.com>
Date:   Fri, 22 Apr 2022 17:17:48 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Javier Martinez Canillas <javierm@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel@...ts.freedesktop.org,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Alex Deucher <alexander.deucher@....com>,
        Borislav Petkov <bp@...e.de>,
        Changcheng Deng <deng.changcheng@....com.cn>,
        Daniel Vetter <daniel@...ll.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        Helge Deller <deller@....de>, Johan Hovold <johan@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Miaoqian Lin <linmq006@...il.com>,
        Peter Jones <pjones@...hat.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Yizhuo Zhai <yzhai003@....edu>,
        Zhen Lei <thunder.leizhen@...wei.com>,
        linux-doc@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [PATCH v3 0/5] Fix some race conditions that exists between
 fbmem and sysfb

On Wed, Apr 20, 2022 at 10:52:58AM +0200, Javier Martinez Canillas wrote:
> Hello,
> 
> The patches in this series are mostly changes suggested by Daniel Vetter
> to fix some race conditions that exists between the fbdev core (fbmem)
> and sysfb with regard to device registration and removal.
> 
> For example, it is currently possible for sysfb to register a platform
> device after a real DRM driver was registered and requested to remove the
> conflicting framebuffers.
> 
> A symptom of this issue, was worked around with by commit fb561bf9abde
> ("fbdev: Prevent probing generic drivers if a FB is already registered")
> but that's really a hack and should be reverted.
> 
> This series attempt to fix it more properly and revert the mentioned hack.
> That will also unblock a pending patch to not make the num_registered_fb
> variable visible to drivers anymore, since that's internal to fbdev core.
> 
> Patch #1 is just a trivial preparatory change.
> 
> Patch #2 add sysfb_disable() and sysfb_try_unregister() helpers for fbmem
> to use them.
> 
> Patch #3 changes how is dealt with conflicting framebuffers unregistering,
> rather than having a variable to determine if a lock should be take, it
> just drops the lock before unregistering the platform device.
> 
> Patch #4 fixes the mentioned race conditions and finally patch #5 is the
> revert patch that was posted by Daniel before but he dropped from his set.
> 
> The patches were tested on a rpi4 using different video configurations:
> (simpledrm -> vc4 both builtin, only vc4 builtin, only simpledrm builtin
> and simpledrm builtin with vc4 built as a module).
> 
> Best regards,
> Javier

Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>