lkml.org 
[lkml]   [2023]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@ffwll.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@ffwll.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

    \
     
     \ /
      Last update: 2023-03-26 23:31    [W:2.796 / U:0.364 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site