Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Helge Deller" <deller@gmx.de>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Bruno Prémont" <bonbons@linux-vserver.org>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Benjamin Tissoires" <bentiss@kernel.org>,
	"Bernie Thompson" <bernie@plugable.com>,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	"Steve Glendinning" <steve.glendinning@shawell.net>,
	"Florian Tobias Schandinat" <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	 linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	 Steve Glendinning <steve.glendinning@smsc.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init()
Date: Mon, 12 Oct 2026 17:48:20 +0100	[thread overview]
Message-ID: <as0PDmzYL5Bc2NrR@gremlin> (raw)
In-Reply-To: <20260926-fix-fbdefio-error-handling-v1-0-a94810b6e263@kernel.org>

On Sat, Sep 26, 2026 at 02:16:58PM +0100, Lorenzo Stoakes (ARM) wrote:
> Commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
> converted fb_deferred_io_init() from a void function to one returning an
> error value.
>
> However a number of callers don't seem to have been apprised of the fact
> and continue to treat it like a void function.
>
> This is problematic, as upon allocation failure, struct
> fb_info->fbdefio_state is NULL.
>
> That means when a subsequent operation is performed upon the driver, for
> instance opening the file, a NULL pointer dereference occurs.
>
> Update all of the remaining drivers which fail to check this to do so.
>
> This issue was discovered as part of a separate series which updated logic
> belonging to ssd1307fb.
>
> Also fix up a separate issue with a BUG_ON() occurring on allocation
> failure for udlfb and smcufx.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> Lorenzo Stoakes (ARM) (6):
>       fbdev: ssd1307fb: check for fb_deferred_io_init() error
>       fbdev: xen-fbfront: check for fb_deferred_io_init() error
>       HID: picoLCD: check for fb_deferred_io_init() error
>       fbdev: udlfb: check for fb_deferred_io_init() error
>       fbdev: smscufx: check for fb_deferred_io_init() error
>       fbdev: sh_mobile_lcdc: check for fb_deferred_io_init() error

Ping on this!

I know timing is awful given a. the insane volume this cycle and b. LPC,
but these are fairly mechanical things so should be relatively
straightforward.

>
>  drivers/hid/hid-picolcd_fb.c           | 12 +++++++++---
>  drivers/video/fbdev/sh_mobile_lcdcfb.c |  6 +++++-
>  drivers/video/fbdev/smscufx.c          |  9 ++++++---
>  drivers/video/fbdev/ssd1307fb.c        |  6 +++++-
>  drivers/video/fbdev/udlfb.c            |  9 ++++++---
>  drivers/video/fbdev/xen-fbfront.c      |  7 ++++++-
>  6 files changed, 37 insertions(+), 12 deletions(-)
> ---
> base-commit: 6812ce4e4379ffc99c52401ec28f0d7ffbc36206
> change-id: 20260926-fix-fbdefio-error-handling-ab135b0193cb
>
> Best regards,
> --
> Lorenzo Stoakes (ARM) <ljs@kernel.org>
>

--
Cheers, Lorenzo

  parent reply	other threads:[~2026-10-12 16:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 13:16 [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init() Lorenzo Stoakes (ARM)
2026-09-26 13:16 ` [PATCH 1/6] fbdev: ssd1307fb: check for fb_deferred_io_init() error Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 2/6] fbdev: xen-fbfront: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 3/6] HID: picoLCD: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 4/6] fbdev: udlfb: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 5/6] fbdev: smscufx: " Lorenzo Stoakes (ARM)
2026-09-26 13:17 ` [PATCH 6/6] fbdev: sh_mobile_lcdc: " Lorenzo Stoakes (ARM)
2026-10-12 16:48 ` Lorenzo Stoakes (ARM) [this message]
2026-10-12 21:07   ` [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init() Helge Deller
2026-10-13 10:17     ` Lorenzo Stoakes (ARM)

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=as0PDmzYL5Bc2NrR@gremlin \
    --to=ljs@kernel.org \
    --cc=FlorianSchandinat@gmx.de \
    --cc=bentiss@kernel.org \
    --cc=bernie@plugable.com \
    --cc=bonbons@linux-vserver.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@suse.de \
    --cc=javierm@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=steve.glendinning@shawell.net \
    --cc=steve.glendinning@smsc.com \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox