> On Jan 6, 2017, at 8:05 AM, Uma Krishnan <ukrishn@xxxxxxxxxxxxxxxxxx> wrote:
>
> When processing an AFU asynchronous interrupt, if the action results in an
> operation that requires off level processing (a link reset for example),
> the worker thread is scheduled. In the meantime a reset event (i.e.: EEH)
> could unmap the AFU to recover. This results in an Oops when the worker
> thread tries to access the AFU mapping.
>
> [c000000f17e03b90] d000000007cd5978 cxlflash_worker_thread+0x268/0x550
> [c000000f17e03c40] c00000000011883c process_one_work+0x1dc/0x680
> [c000000f17e03ce0] c000000000118e80 worker_thread+0x1a0/0x520
> [c000000f17e03d80] c000000000126174 kthread+0xf4/0x100
> [c000000f17e03e30] c00000000000a47c ret_from_kernel_thread+0x5c/0xe0
>
> In an effort to avoid this, a mapcount was introduced in
> commit b45cdbaf9f7f ("cxlflash: Resolve oops in wait_port_offline")
> but due to the race condition described above, this solution is incomplete.
>
> In order to fully resolve this problem and to simplify things, this commit
> removes the mapcount solution. Instead, the scheduled worker thread is
> cancelled after interrupts have been disabled and prior to the mapping
> being freed.
>
> Fixes: b45cdbaf9f7f ("cxlflash: Resolve oops in wait_port_offline")
> Signed-off-by: Uma Krishnan <ukrishn@xxxxxxxxxxxxxxxxxx>
Looks good.
Acked-by: Matthew R. Ochs <mrochs@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
