On 2020/1/8 23:07, Christoph Hellwig wrote:
On Tue, Jan 07, 2020 at 02:51:04PM +0800, renxudong wrote:
When we issued scsi cmd, oops occurred. The call stack was as follows.
Call trace:
__memcpy+0x110/0x180
bio_endio+0x118/0x190
blk_update_request+0x94/0x378
scsi_end_request+0x48/0x2a8
scsi_io_completion+0xa4/0x6d0
scsi_finish_command+0xd4/0x138
scsi_softirq_done+0x13c/0x198
blk_done_softirq+0xc4/0x108
__do_softirq+0x120/0x324
run_ksoftirqd+0x44/0x60
smpboot_thread_fn+0x1ac/0x1e8
kthread+0x134/0x138
ret_from_fork+0x10/0x18
Since oops is in the process of scsi cmd done, we have not added oops info
to the commit log.
What workload is this? If the address is freed while the I/O is
in progress we have much deeper problem than what a virt_addr_valid
could paper over.
.
Indeed, if the address has been released, the data stored by the current
owner of the memory will be destroyed, but I did not think of a better
way to avoid the use after free situation when issuing scsi cmd
