Hi,
On 1/27/24 20:53, Gustavo A. R. Silva wrote:
On 1/27/24 09:11, David Laight wrote:
From: Linus Torvalds
Sent: 26 January 2024 22:36
On Fri, 26 Jan 2024 at 14:24, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
I think xe has some other weird problems too. This may be related
(under
allocating):
../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create':
../drivers/gpu/drm/xe/xe_vm.c:806:21: warning: allocation of
insufficient size '224' for type
'struct xe_vma' with size '368' [-Walloc-size]
806 | vma = kzalloc(sizeof(*vma) - sizeof(struct
xe_userptr),
| ^
That code is indeed odd, but there's a comment in the xe_vma definition
/**
* @userptr: user pointer state, only allocated for VMAs
that are
* user pointers
*/
struct xe_userptr userptr;
although I agree that it should probably simply be made a final
variably-sized array instead (and then you make that array size be
0/1).
That entire code is odd.
It isn't obvious that the flag values that cause the short allocate
are the same ones that control whether the extra data is accessed.
Never mind the oddities with the 'flags |= ' assignments int the
'remap next' path.
Anyone know how many of these actually get allocated (and their
lifetimes)?
How much difference would it make to allocate 368 (maybe 384?)
bytes instead of 224 (likely 256).
[CC+ xen list and maintainers]
Probably the xen maintainer can help us out here.
Unfortunately the number of these can be quite large, and with a long
lifetime which I guess was the reason that size optimization was done in
the first place.
Ideally IMO this should've been subclassed to an xe_userptr_vma, but
until we have a chance to clean that up, We can look at the
variable-sized array or simply allocate the full size until we get to that.
Thanks,
Thomas
--
Gustavo
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
MK1 1PT, UK
Registration No: 1397386 (Wales)
