> On Jun 15, 2016, at 6:49 PM, Uma Krishnan <ukri...@linux.vnet.ibm.com> wrote: > > From: "Manoj N. Kumar" <ma...@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 <ma...@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mro...@linux.vnet.ibm.com> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
