[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y7iQckF/6EMYVpQt@phenom.ffwll.local>
Date: Fri, 6 Jan 2023 22:19:46 +0100
From: Daniel Vetter <daniel@...ll.ch>
To: Hang Zhang <zh.nvgt@...il.com>
Cc: Helge Deller <deller@....de>,
Javier Martinez Canillas <javierm@...hat.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Sam Ravnborg <sam@...nborg.org>,
Alex Deucher <alexander.deucher@....com>,
linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] fbmem: prevent potential use-after-free issues with
console_lock()
On Fri, Jan 06, 2023 at 03:25:14PM -0500, Hang Zhang wrote:
> On Fri, Jan 6, 2023 at 3:05 PM Daniel Vetter <daniel@...ll.ch> wrote:
> > On Fri, Jan 06, 2023 at 02:58:27PM -0500, Hang Zhang wrote:
> > > On Fri, Jan 6, 2023 at 1:59 PM Daniel Vetter <daniel@...ll.ch> wrote:
> > > BTW, if this is worthed a fix and the performance of console_lock() is a
> > > major concern, then I think there may be alternative solutions like adding
> > > a lock_fb_info() to the free call chain - if that's better in performance,
> > > or maybe selectively protect the matroxfb ioctl but not vblank ioctl as you
> > > mentioned.
> >
> > Please start out with explaining what kind of bug your checker is seeing,
> > and why. Not how you're trying to fix it. Because I'm pretty sure there
> > isn't a bug, but since I've already spent a pile of time looking at this,
> > I want to make sure.
>
> We are sorry for the inconvenience caused, we'll follow these practices and
> guidelines in the future. Thank you!
Once more: Please explain what you're static checker is seeing. I want to
understanding this, and I'm hoping at least someone involved in this
static checker can explain what it thinks is going on.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists