Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 4 May 2022 11:49:29 +0200
From:   Daniel Vetter <daniel@ffwll.ch>
To:     Javier Martinez Canillas <javierm@redhat.com>
Cc:     linux-kernel@vger.kernel.org, Maxime Ripard <maxime@cerno.tech>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Junxiao Chang <junxiao.chang@intel.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Changcheng Deng <deng.changcheng@zte.com.cn>,
        Daniel Vetter <daniel@ffwll.ch>,
        Hans de Goede <hdegoede@redhat.com>,
        Helge Deller <deller@gmx.de>, Sam Ravnborg <sam@ravnborg.org>,
        Xiyu Yang <xiyuyang19@fudan.edu.cn>,
        Zack Rusin <zackr@vmware.com>,
        Zhen Lei <thunder.leizhen@huawei.com>,
        Zheyu Ma <zheyuma97@gmail.com>,
        Zhouyi Zhou <zhouzhouyi@gmail.com>,
        dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2] fbdev: Make fb_release() return -ENODEV if fbdev was
 unregistered
Message-ID: <YnJMKcz+C32x0sOv@phenom.ffwll.local>
Mail-Followup-To: Javier Martinez Canillas <javierm@redhat.com>,
        linux-kernel@vger.kernel.org, Maxime Ripard <maxime@cerno.tech>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Junxiao Chang <junxiao.chang@intel.com>,
        Alex Deucher <alexander.deucher@amd.com>,
        Changcheng Deng <deng.changcheng@zte.com.cn>,
        Hans de Goede <hdegoede@redhat.com>, Helge Deller <deller@gmx.de>,
        Sam Ravnborg <sam@ravnborg.org>,
        Xiyu Yang <xiyuyang19@fudan.edu.cn>, Zack Rusin <zackr@vmware.com>,
        Zhen Lei <thunder.leizhen@huawei.com>,
        Zheyu Ma <zheyuma97@gmail.com>, Zhouyi Zhou <zhouzhouyi@gmail.com>,
        dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org
References: <20220502135014.377945-1-javierm@redhat.com>
 <e3ce080c-8ef8-f838-d4a8-b10cd5d5c172@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e3ce080c-8ef8-f838-d4a8-b10cd5d5c172@redhat.com>
Precedence: bulk

On Tue, May 03, 2022 at 05:28:09PM +0200, Javier Martinez Canillas wrote:
> On 5/2/22 15:50, Javier Martinez Canillas wrote:
> > A reference to the framebuffer device struct fb_info is stored in the file
> > private data, but this reference could no longer be valid and must not be
> > accessed directly. Instead, the file_fb_info() accessor function must be
> > used since it does sanity checking to make sure that the fb_info is valid.
> > 
> > This can happen for example if the registered framebuffer device is for a
> > driver that just uses a framebuffer provided by the system firmware. In
> > that case, the fbdev core would unregister the framebuffer device when a
> > real video driver is probed and ask to remove conflicting framebuffers.
> > 
> > The bug has been present for a long time but commit 27599aacbaef ("fbdev:
> > Hot-unplug firmware fb devices on forced removal") unmasked it since the
> > fbdev core started unregistering the framebuffers' devices associated.
> > 
> > Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
> > Reported-by: Maxime Ripard <maxime@cerno.tech>
> > Reported-by: Junxiao Chang <junxiao.chang@intel.com>
> > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> Applied to drm-misc (drm-misc-fixes).

See my other reply, but how does this not result in leaks?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch