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

[Helge Deller <deller@gmx.de>]

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:
>> 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