Panic in nvme_fill_prp() because of miscalculation of the number of PRPs per page
nprp_page = nvme->n_pagesize / sizeof (uint64_t) - 1; ASSERT(nprp_page > 0); nprp = (xfer->x_ndmac + nprp_page - 1) / nprp_page; /* * We currently don't support chained PRPs and set up our DMA * attributes to reflect that. If we still get an I/O request * that needs a chained PRP something is very wrong. */ VERIFY(nprp == 1);
System can panic at the verify because the nprp_page is calculated as one to few. (First line in the snippet).
Updated by Electric Monk 6 days ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
commit 0999c1123c1ab769df080ccc5f1626d50663e7a8 Author: Paul Winder <Paul.Winder@wdc.com> Date: 2019-06-20T14:02:46.000Z 11202 Allow the number of NVMe submission and completion queues to be different 11228 nvme may queue more submissions than allowed 11229 nvme_get_logpage() can allocate a too small buffer to receive logpage data 11230 Panic in nvme_fill_prp() because of miscalculation of the number of PRPs per page 11231 nvme in polled mode ignores the command call back Reviewed by: Robert Mustacchi <email@example.com> Reviewed by: Hans Rosenfeld <firstname.lastname@example.org> Reviewed by: Gergő Mihály Doma <email@example.com> Reviewed by: Youzhong Yang <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>