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>).

The issue is that netfs_consume_read_data() assumes it runs in process
or softirq context, but cachefiles_read_complete() can be called
directly from block layer IRQ completion (iomap_dio_bio_end_io), which
runs in hard IRQ context.

This triggers ~6 seconds after boot once NFS mounts with fsc come up
and the first cached reads complete from the NVMe backing store.

I have only seen this once so far. The system continued running but
cachefilesd appears to have died shortly after (possibly related).

Full trace:

Hello,

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

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