Am 21.05.19 um 09:23 schrieb Daniel Vetter:
On Tue, May 21, 2019 at 4:33 AM Alex Deucher <alexdeucher@xxxxxxxxx> wrote:
On Mon, May 20, 2019 at 7:19 PM Pan, Xinhui <Xinhui.Pan@xxxxxxx> wrote:
Daniel, what you are talking about is totally wrong.
1) AFAIK, only one zero-size array can be in the end of a struct.
2) two struct_size will add up struct itself twice. the sum is wrong then.
No offense. I can't help feeling lucky that you are in intel.
Xinhui,
Please keep things civil. There is no need for comments like this.
Yeah, this was over the line, thanks Alex for already taking care of
this. Please note that fd.o mailing lists operate under a CoC:
https://www.freedesktop.org/wiki/CodeOfConduct/
Seconded. I also enjoy the humiliation of other in email, but it doesn't
helps us getting code written and problems solved in a professional
environment.
Wrt the technical comment: I know that you can only do one variable
sized array, and it must be at the end. But you can put multiple
structures all within the same allocation. Which is what I thought you
wanted to do. And my sketch would allow you to do that even if you
have multiple variable length structures you want to allocate. There's
plenty examples of this (but open-coded ones) in the kernel.
BTW: Is there actually good documentation how to correctly do the
variable length array at end of structure thing in the kernel?
I do know that I've seen a lot of different variants like array[]
array[0] or array[1] and I have also seen a bunch of gcc versions
failing to generate correct code for some of them.
So we should probably nail down how to do things correctly.
Except in really hot paths I personally think that that kind of
trickery isn't worth it.
Well for kmalloc() it's not that much overhead, but with vmalloc that is
a completely different picture.
Christian.
Cheers, Daniel
Alex
发件人: Daniel Vetter <daniel.vetter@xxxxxxxx> 代表 Daniel Vetter <daniel@xxxxxxxx>
发送时间: 2019年5月21日 0:28
收件人: Pan, Xinhui
抄送: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); airlied@xxxxxxxx; daniel@xxxxxxxx; Quan, Evan; xiaolinkui; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
主题: Re: [PATCH] gpu: drm: use struct_size() in kmalloc()
[CAUTION: External Email]
On Fri, May 17, 2019 at 04:44:30PM +0000, Pan, Xinhui wrote:
I am going to put more members which are also array after this struct,
not only obj[]. Looks like this struct_size did not help on multiple
array case. Thanks anyway. ________________________________
You can then add them up, e.g. kmalloc(struct_size()+struct_size(),
GFP_KERNEL), so this patch here still looks like a good idea.
Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
Cheers, Daniel
From: xiaolinkui <xiaolinkui@xxxxxxxxxx>
Sent: Friday, May 17, 2019 4:46:00 PM
To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); airlied@xxxxxxxx; daniel@xxxxxxxx; Pan, Xinhui; Quan, Evan
Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; xiaolinkui@xxxxxxxxxx
Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
[CAUTION: External Email]
Use struct_size() helper to keep code simple.
Signed-off-by: xiaolinkui <xiaolinkui@xxxxxxxxxx>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 22bd21e..4717a64 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
if (con)
return 0;
- con = kmalloc(sizeof(struct amdgpu_ras) +
- sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
+ con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
GFP_KERNEL|__GFP_ZERO);
if (!con)
return -ENOMEM;
--
2.7.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
