Am 17.03.21 um 10:40 schrieb Chen Li:
On Wed, 17 Mar 2021 17:19:11 +0800,
Chen Li wrote:
On Wed, 17 Mar 2021 15:55:47 +0800,
Christian König wrote:
Am 17.03.21 um 07:22 schrieb Chen Li:
kvmalloc_array + __GFP_ZERO is the same with kvcalloc.
As for p->chunks, it will be used in:
```
if (ib_chunk->kdata)
memcpy(parser->ib.ptr, ib_chunk->kdata, ib_chunk->length_dw *
4);
```
If chunks doesn't zero out with __GFP_ZERO, it may point to somewhere else,
e.g.,
```
Unable to handle kernel paging request at virtual address 0000000000010000
...
pc is at memcpy+0x84/0x250
ra is at radeon_cs_ioctl+0x368/0xb90 [radeon]
```
after allocating chunks with __GFP_KERNEL/kvcalloc, this bug is fixed.
NAK to zeroing the chunks array.
That array should be fully initialized with data before using it, otherwise we
have a much more serious bug and zeroing it out only papers over the real issue.
How did you trigger the NULL pointer deref above?
Hi, Christian, thanks for reply! From radeon_cs_parser_init:
```
if (user_chunk.chunk_id == RADEON_CHUNK_ID_IB) {
if (!p->rdev || !(p->rdev->flags & RADEON_IS_AGP))
/****** chenli: chunks[0] come here and continue! ******/
continue;
}
p->chunks[i].kdata = kvmalloc_array(size, sizeof(uint32_t),
GFP_KERNEL);
```
In my case, chunks[0] is not allocated because it is just get continued, so
it's not
wired that kdata in "memcpy(parser->ib.ptr, ib_chunk->kdata, ib_chunk->length_dw *
4);"
trigger the invalid address.
By the ways, chunks were allocated with kcalloc before
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2Fcommit%2F%3Fid%3D3fcb4f01deedfa290e903e030956b8e1a5cb764f&data=04%7C01%7Cchristian.koenig%40amd.com%7Ca2386f016a6f40d910a808d8e928a88f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637515708138849091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ztgRwRsRLV%2FUYqaWvCrQ9WGEEVh6x3a4%2FHZyS%2F%2FttBc%3D&reserved=0,
which do zero the chunks array, that's why this error never happen before.
Ah! I was really wondering why that worked all those years.
We try to avoid kcalloc and similar in new code because it is often used
as a wildcard to paper over real problems and disables KASAN checks
etc... But when this is just restoring old behavior it is probably ok.
Please add a Fixes: tag pointing to the original commit which introduced
the problem so that backporters can handle that properly.
With that done the patch is Reviewed-by: Christian König
<[email protected]>
Thanks,
Christian.
Thanks,
Christian.
Signed-off-by: Chen Li <[email protected]>
---
drivers/gpu/drm/radeon/radeon_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index fb736ef9f9aa..059431689c2d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -93,8 +93,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
p->dma_reloc_idx = 0;
/* FIXME: we assume that each relocs use 4 dwords */
p->nrelocs = chunk->length_dw / 4;
- p->relocs = kvmalloc_array(p->nrelocs, sizeof(struct radeon_bo_list),
- GFP_KERNEL | __GFP_ZERO);
+ p->relocs = kvcalloc(p->nrelocs, sizeof(struct radeon_bo_list),
+ GFP_KERNEL);
if (p->relocs == NULL) {
return -ENOMEM;
}
@@ -299,7 +299,7 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
}
p->cs_flags = 0;
p->nchunks = cs->num_chunks;
- p->chunks = kvmalloc_array(p->nchunks, sizeof(struct radeon_cs_chunk),
GFP_KERNEL);
+ p->chunks = kvcalloc(p->nchunks, sizeof(struct radeon_cs_chunk),
GFP_KERNEL);
if (p->chunks == NULL) {
return -ENOMEM;
}
Regards,
Chen Li
Regards,
Chen Li
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
