[PATCH 1/3] cxlflash: Fix to drain operations from previous reset
Matthew R. Ochs
mrochs at linux.vnet.ibm.com
Mon Jun 20 23:47:09 AEST 2016
> On Jun 15, 2016, at 6:49 PM, Uma Krishnan <ukrishn at linux.vnet.ibm.com> wrote:
>
> From: "Manoj N. Kumar" <manoj at linux.vnet.ibm.com>
>
> While running 'sg_reset -H' in a loop with a user-space application active,
> hit the following exception:
>
> cpu 0x2: Vector: 300 (Data Access)
> pc: : afu_attach+0x50/0x240 [cxlflash]
> lr: : cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash]
> pid = 20365, comm = run_block_fvt
>
> Linux version 4.5.0-491-26f710d+
>
> cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash]
> cxlflash_ioctl+0x5a8/0x6f0 [cxlflash]
> scsi_ioctl+0x3b0/0x4c0
> sd_ioctl+0x110/0x190
> blkdev_ioctl+0x28c/0xc20
> block_ioctl+0xa4/0xd0
> do_vfs_ioctl+0xd8/0x8c0
> SyS_ioctl+0xd4/0xf0
> system_call+0x38/0xb4
>
> The problem here is that the problem space area is unmapped while the
> application issues the DK_CXLFLASH_RECOVER_AFU ioctl.
>
> This is the order I observe:
>
> proc1 proc2
> 1) sg_reset
> 2) ioctl(DK_CXLFLASH_RECOVER_AFU)
> 3) sg_reset again
> causing a PSA unmap
> 4) continues RECOVER_AFU processing
>
> The resolution to this problem is to have the reset handler drain all
> outstanding user space initiated ioctls before proceeding. It is safe
> to drain after the state has been changed to STATE_RESET. Also since
> drain_ioctls() was static, it had to be moved up a bit to be before
> cxlflash_eh_host_reset_handler().
>
> Signed-off-by: Manoj N. Kumar <manoj at linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs at linux.vnet.ibm.com>
More information about the Linuxppc-dev
mailing list