All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Hang Zhang <zh.nvgt@gmail.com>
Cc: Helge Deller <deller@gmx.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Sam Ravnborg <sam@ravnborg.org>,
	Alex Deucher <alexander.deucher@amd.com>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] fbmem: prevent potential use-after-free issues with console_lock()
Date: Fri, 6 Jan 2023 22:19:46 +0100	[thread overview]
Message-ID: <Y7iQckF/6EMYVpQt@phenom.ffwll.local> (raw)
In-Reply-To: <CAO2zrtaB3GZRSzgWu2kV_jTojwuhtL_kFz0gpzPPVGe9D8kVbQ@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Hang Zhang <zh.nvgt@gmail.com>
Cc: linux-fbdev@vger.kernel.org, Helge Deller <deller@gmx.de>,
	Javier Martinez Canillas <javierm@redhat.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Alex Deucher <alexander.deucher@amd.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] fbmem: prevent potential use-after-free issues with console_lock()
Date: Fri, 6 Jan 2023 22:19:46 +0100	[thread overview]
Message-ID: <Y7iQckF/6EMYVpQt@phenom.ffwll.local> (raw)
In-Reply-To: <CAO2zrtaB3GZRSzgWu2kV_jTojwuhtL_kFz0gpzPPVGe9D8kVbQ@mail.gmail.com>

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

  reply	other threads:[~2023-01-06 21:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  6:35 [PATCH] fbmem: prevent potential use-after-free issues with console_lock() Hang Zhang
2022-12-30  6:35 ` Hang Zhang
2023-01-02 15:28 ` Helge Deller
2023-01-02 15:28   ` Helge Deller
2023-01-05 10:21   ` Daniel Vetter
2023-01-05 10:21     ` Daniel Vetter
2023-01-05 10:25     ` Daniel Vetter
2023-01-05 10:25       ` Daniel Vetter
2023-01-05 18:38       ` Hang Zhang
2023-01-05 18:38         ` Hang Zhang
2023-01-06 18:59         ` Daniel Vetter
2023-01-06 18:59           ` Daniel Vetter
2023-01-06 19:58           ` Hang Zhang
2023-01-06 19:58             ` Hang Zhang
2023-01-06 20:05             ` Daniel Vetter
2023-01-06 20:05               ` Daniel Vetter
2023-01-06 20:25               ` Hang Zhang
2023-01-06 20:25                 ` Hang Zhang
2023-01-06 21:19                 ` Daniel Vetter [this message]
2023-01-06 21:19                   ` Daniel Vetter
2023-01-06 22:12                   ` Hang Zhang
2023-01-06 22:12                     ` Hang Zhang
2023-01-06 22:46                     ` Daniel Vetter
2023-01-06 22:46                       ` Daniel Vetter
2023-01-06 23:19                       ` Hang Zhang
2023-01-06 23:19                         ` Hang Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7iQckF/6EMYVpQt@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=alexander.deucher@amd.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tzimmermann@suse.de \
    --cc=zh.nvgt@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.