On Thu, Feb 2, 2023 at 2:58 PM Song Liu [off-list ref] wrote:

On Wed, Feb 1, 2023 at 4:41 PM Xiao Ni [off-list ref] wrote:

quoted

On Thu, Feb 2, 2023 at 8:23 AM Xiao Ni [off-list ref] wrote:

quoted

On Thu, Feb 2, 2023 at 2:00 AM Song Liu [off-list ref] wrote:

quoted

On Wed, Feb 1, 2023 at 4:46 AM Xiao Ni [off-list ref] wrote:

quoted

It has added io_acct_set for raid0/raid5 io accounting and it needs to
alloc md_io_acct in the i/o path. They are free when the bios come back
from member disks. Now we don't have a method to monitor if those bios
are all come back. In the takeover process, it needs to free the raid0
memory resource including the memory pool for md_io_acct. But maybe some
bios are still not returned. When those bios are returned, it can cause
panic bcause of introducing NULL pointer or invalid address. Something
like this:

Can we use mddev->active_io for this? If not, please explain the reason
in the comments (in the code).

Hi Song

At first, we thought this way. Now ->acitve_io is used to wait all
submit processes to exit.
If we use ->active_io to count acct_bio, it means we change the usage
of ->active_io.
In mddev_suspend, first it waits for all submit processes to finish,
then it calls ->quiesce
to wait all inflight io to come back. For raid0, it's ok to use
->acitve_io to count acct_bio.
But for raid5, not sure if it's ok. What's your opinion?

Hi Song

I've sent V4. If you think ->active_io is a better way to count acct_io,
I'll re-write the patch to use ->active_io

I haven't thought about all the details. But we should try very hard to
avoid adding another percpu_ref. So let's try to use active_io to count
acct_io.

Thanks,
Song

Ok, I'll try to send a version using active_io.

Regards
Xiao