On Thu, Sep 17, 2020 at 11:32:12PM -0400, Tong Zhang wrote:
> Please correct me if I am wrong.
> After a bit more digging I found out that it is indeed command_id got
> corrupted is causing this problem. Although the tag and command_id
> range is checked like you said, the elements in rqs cannot
Please correct me if I am wrong.
After a bit more digging I found out that it is indeed command_id got
corrupted is causing this problem. Although the tag and command_id
range is checked like you said, the elements in rqs cannot be
guaranteed to be not NULL. thus although the range check is
Hmm..Yeah.. I see your point.
I was naivly thinking the command_id was the culprit.
On Thu, Sep 17, 2020 at 1:14 PM Keith Busch wrote:
>
> On Thu, Sep 17, 2020 at 12:56:59PM -0400, Tong Zhang wrote:
> > The command_id in CQE is writable by NVMe controller, driver should
> > check its sanity
On Thu, Sep 17, 2020 at 12:56:59PM -0400, Tong Zhang wrote:
> The command_id in CQE is writable by NVMe controller, driver should
> check its sanity before using it.
We already do that.
The command_id in CQE is writable by NVMe controller, driver should
check its sanity before using it.
- Tong
On Wed, Sep 16, 2020 at 12:54 PM Keith Busch wrote:
>
> On Wed, Sep 16, 2020 at 11:36:49AM -0400, Tong Zhang wrote:
> > @@ -960,6 +960,8 @@ static inline void nvme_handle_cqe(struct
On Wed, Sep 16, 2020 at 11:36:49AM -0400, Tong Zhang wrote:
> @@ -960,6 +960,8 @@ static inline void nvme_handle_cqe(struct nvme_queue
> *nvmeq, u16 idx)
> }
>
> req = blk_mq_tag_to_rq(nvme_queue_tagset(nvmeq), cqe->command_id);
> + if (!req)
> + return;
As I
blk_mq_tag_to_rq can return NULL and this condition must be checked
[ 147.861050] BUG: KASAN: null-ptr-deref in nvme_irq+0xfc/0x410
[ 147.861326] Write of size 2 at addr 0122 by task kworker/u4:1/56
[ 147.861675]
[ 147.861756] CPU: 1 PID: 56 Comm: kworker/u4:1 Not tainted
7 matches
Mail list logo
