Re: [PATCH bpf-next 0/6] workqueue: introduce BPF iterators for workqueues, worker pools and pending work

On Thu, Aug 6, 2026 at 1:49 AM <[email protected]> wrote:
>
> On 2/8/2026 10:59 am, Tejun Heo wrote:
> Hello Tejun,
> Thanks for taking a look into this.
>
> > Hello,
> >
> > On Tue, Jul 28, 2026 at 02:55:19PM +0800, Imran Khan wrote:
> >> Nearly every subsystem defers work to workqueues, and their state can
> >> already be observed on a live system, just not at a granularity that is
> >> convenient to consume. sysrq dumps every workqueue and pool to the kernel
> >> log in a fixed format, with no way to select or aggregate; the WQ_SYSFS
> >> interface only covers workqueues that ask for it and exposes attributes
> >> rather than runtime state; and the drgn scripts under tools/workqueue/ need
> >> a debuginfo-equipped userspace and read the state from the outside, without
> >> the locks that protect it.
> >>
> >> This series adds BPF iterators for workqueues, worker pools and pending
> >> work items, so that this state can be walked from inside the kernel, under
> >> the right locking, with filtering and aggregation done in place and only
> >> the interesting part copied to userspace.
> >
> > I'm not necessarily against it but what are the use cases here? If for
> > debugging, isn't drgn + hooking into tracepoints mostly enough? Can you give
> > concrete examples where bpf iterators are essential?
> >
>
> The main use case is being able to peek at workqueue state right when a problem
> (where checking workqueue state makes sense) is detected.
> One very common case for us is getting RDS TX timeouts because of the the stuck work items.
> At the moment I don't have a system where I can both use the patched kernel and
> reproduce the Tx timeout issue, so I have tried to explain the same using block
> layer and dm-device as affected subsystem.
>

Looking at open-coded iter implementation, it seems like you should be
able to implement this pretty easily with just bpf_for() loop and
bpf_core_cast() primitives. If it's for diagnostics and debugging,
wouldn't that be sufficient?


[...]