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.
