From: renxudong <renxudong1@huawei.com>
To: Bart Van Assche <bvanassche@acm.org>,
Christoph Hellwig <hch@infradead.org>
Cc: Bob Liu <bob.liu@oracle.com>,
Zhiqiang Liu <liuzhiqiang26@huawei.com>,
Jens Axboe <axboe@kernel.dk>, <linux-block@vger.kernel.org>,
<jens.axboe@oracle.com>, <namhyung@gmail.com>,
<bharrosh@panasas.com>, Mingfangsen <mingfangsen@huawei.com>,
<zhengbin13@huawei.com>, Guiyao <guiyao@huawei.com>,
<ming.lei@redhat.com>
Subject: Re: [PATCH] blk-map: add kernel address validation in blk_rq_map_kern func
Date: Mon, 13 Jan 2020 14:32:49 +0800 [thread overview]
Message-ID: <192eac2b-ff16-f6fe-40ea-b1ec3b7aab9e@huawei.com> (raw)
In-Reply-To: <5de25176-88ff-2c2b-7282-fadc0cab2065@acm.org>
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.
next prev parent reply other threads:[~2020-01-13 6:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 12:17 [PATCH] blk-map: add kernel address validation in blk_rq_map_kern func Zhiqiang Liu
2020-01-07 2:38 ` Zhiqiang Liu
2020-01-07 4:05 ` Bob Liu
2020-01-07 6:51 ` renxudong
2020-01-08 15:07 ` Christoph Hellwig
2020-01-12 0:18 ` Bart Van Assche
2020-01-13 6:32 ` renxudong [this message]
2020-01-13 3:53 ` renxudong
2020-01-07 4:02 ` Jens Axboe
2020-01-08 13:31 ` Christoph Hellwig
2020-01-13 3:22 ` renxudong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=192eac2b-ff16-f6fe-40ea-b1ec3b7aab9e@huawei.com \
--to=renxudong1@huawei.com \
--cc=axboe@kernel.dk \
--cc=bharrosh@panasas.com \
--cc=bob.liu@oracle.com \
--cc=bvanassche@acm.org \
--cc=guiyao@huawei.com \
--cc=hch@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=ming.lei@redhat.com \
--cc=mingfangsen@huawei.com \
--cc=namhyung@gmail.com \
--cc=zhengbin13@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).