@@ -4984,7 +4984,7 @@ base_alloc_rdpq_dma_pool(struct MPT3SAS_ADAPTER *ioc, int sz)
for (i = 0; i < count; i++) {
if ((i % RDPQ_MAX_INDEX_IN_ONE_CHUNK == 0) && dma_alloc_count) {
ioc->reply_post[i].reply_post_free =
- dma_pool_alloc(ioc->reply_post_free_dma_pool,
+ dma_pool_zalloc(ioc->reply_post_free_dma_pool,
GFP_KERNEL,
&ioc->reply_post[i].reply_post_free_dma);
if (!ioc->reply_post[i].reply_post_free)
@@ -5008,9 +5008,6 @@ base_alloc_rdpq_dma_pool(struct MPT3SAS_ADAPTER *ioc, int sz)
ioc->reply_post[i].reply_post_free_dma));
return -EAGAIN;
}
- memset(ioc->reply_post[i].reply_post_free, 0,
- RDPQ_MAX_INDEX_IN_ONE_CHUNK *
- reply_post_free_sz);
dma_alloc_count--;
} else {
Replace dma_pool_alloc and memset with dma_pool_zalloc. This fixes memset accessing out of range address when reply_queue count is less than RDPQ_MAX_INDEX_IN_ONE_CHUNK (i.e. 16) in non-RDPQ mode. In non-RDPQ mode, the driver allocates a single contiguous pool of size reply_queue's count * reqly_post_free_sz. But here the driver is always memsetting this pool with size 16 * reqly_post_free_sz. so if reply queue count is less then 16 (i.e. when msix vectors enabled is less then 16) then the driver is accessing out of range address and this results in 'BUG: unable to handle kernel paging request at fff0x...x' bug. This bug got introduced from below commit id, commit 8012209eb26b7819385a6ec6eae4b1d0a0dbe585 ("scsi: mpt3sas: Handle RDPQ DMA allocation in same 4G region") To fix this out of range access, the driver uses dma_pool_zalloc API to allocate the pool. so that this pool will be initialized with zeros of actual pool size by this API itself Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com> --- drivers/scsi/mpt3sas/mpt3sas_base.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)