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

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Scott Tringali]

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