Re: Bug#1137107: netfs local_bh_enable in hard IRQ via cachefiles read completion

[Scott Tringali <stringal@mathworks.com>]

Wish I could - I’m in a restricted/puppet’d environment and can’t make changes like that.

> On May 27, 2026, at 9:22 AM, Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:
> 
> Control: tag -1 + upstream moreinfo
> 
> Hello,
> 
> On Tue, May 19, 2026 at 02:50:32PM -0400, Scott Tringali wrote:
>> Package: linux
>> Severity: important
>> Tags: patch
>> X-Debbugs-Cc: stringal@mathworks.com
>> 
>> Package: linux
>> Version: 6.12.86-1
>> Severity: important
>> Tags: upstream
>> 
>> netfs_consume_read_data() calls local_bh_enable() in hard IRQ context
>> when reached via the cachefiles async read completion path.
>> 
>> The call chain is:
>> 
>>  nvme_irq                              [hard IRQ]
>>    blk_mq_end_request_batch
>>      iomap_dio_bio_end_io
>>        cachefiles_read_complete        [cachefiles]
>>          netfs_read_subreq_terminated  [netfs]
>>            netfs_consume_read_data     [netfs]
>>              __local_bh_enable_ip      *** WARNING ***
>> 
>> This fires a WARN_ON at kernel/softirq.c:386 because local_bh_enable()
>> is called while in hard IRQ context (PID 0, swapper, inside <IRQ>).
> 
> There was a similar report filed upstream at
> https://lore.kernel.org/all/CAKPOu+_4m80thNy5_fvROoxBm689YtA0dZ-=gcmkzwYSY4syqw@mail.gmail.com/
> 
> The patches mentioned there went into 6.14-rc1[1], though they didn't
> fix all issues for the reporter there.
> 
> So I think the right course of action is to test a newer kernel first,
> and if that helps (and I assume it does), prod David (on Cc:) about
> maybe backporting the fixes to v6.12.y.
> 
> So Scott, you you please check if the kernel from unstable/testing or
> backports fixes things for you?
> 
> Best regards
> Uwe
> 
> [1] https://lore.kernel.org/linus/ca56a74a31e26d81a481304ed2f631e65883372b