On 2020/1/12 8:18, Bart Van Assche wrote:
On 2020-01-08 07: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.
Hi Zhiqiang Liu and renxudong,
I have not yet encountered the above callstack myself but I'm also
interested to learn more about the workload. Is this call trace e.g.
only triggered by one particular SCSI LLD?
Thanks,
Bart.
.
Sorry, I haven't been able to respond to your e-mails in time.
The above callstack is trrigered because the address passed by our
modeules is illegal. When IO is completed, the destination address of
memcpy is an illegal address, and the oops appear.
