Re: [PATCH 0/6] fbdev: fixup callers which ignore errors from fb_deferred_io_init()

Hi Lorenzo,

On 10/12/26 18:48, Lorenzo Stoakes (ARM) wrote:

On Sat, Sep 26, 2026 at 02:16:58PM +0100, Lorenzo Stoakes (ARM) wrote:

quoted

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!

Thank you for those patches!
I've applied them now to the fbdev/for-next git tree.

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.

Yes, but still I hesitate to push it for 7.3, as it seems quite unlikely
that a normal installation will run into this memory leak.
So, I think this can wait for 7.4-rc1, right?

Helge