[Crash-utility] [PATCH v2] Handle blk_mq_ctx member changes for kernels v5.16-rc1~75^2~44

[lijiang]

Hi,  Steffen and Kazu
Sorry, I missed this information.

On Tue, Jan 4, 2022 at 9:10 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at nec.com>
wrote:

> -----Original Message-----
> > Admittedly, I haven't looked into the details, but those simple numbers
> for
> > pending IO have been very valuable for me, when analyzing dumps with
> > dm-multipath over (FC-attached) SCSI disks. Aren't those pending IO
> numbers
> > available elsewhere in the kernel? Maybe not in debugfs anymore, but I
> suppose
> > the (mq) block layer does keep track of them?
>
> AFAIK, unfortunately there is no simple counter, crash needs to parse
> sbitmap
> structures to count them.  (please let us know if there is a simpler
> solution.)
> Currently Sergey has worked on adding sbitmap function [1], and we plan to
> make
> use of it after merging the patch.  It may take some time, so Lianbo's
> patch is
> a temporary workaround for the error.
>

In addition, I would like to add that the counter for the
ctx->rq_completed/ctx->rq_dispatched(for 'dev -d') may become inaccurate
due to racing per-cpu values in the kernel. I'm considering whether crash
should print a warning or "not supported" for "dev -d", which can avoid
misleading users. So far we have encountered two similar cases.

What's your opinion?Kazu.

BTW: Also added IIya to cc list.

Thanks.
Lianbo

Maybe it was better to write the status on the commit log..
>
> [1]
> https://listman.redhat.com/archives/crash-utility/2021-December/msg00062.html
>
> Thanks,
> Kazu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20220214/e5cbef4d/attachment.htm>