On Sat, Mar 15, 2025 at 08:31:21AM -1000, Linus Torvalds wrote:
> Alternatively, this might be acceptable if the syntax makes mistakes
> much harder to do. So for example, if it wasn't just an assignment,
> but also declared the 'ptr' variable, maybe it would become much safer
> simply because it w
On Sat, Mar 15, 2025 at 03:48:30PM +1030, Gustavo A. R. Silva wrote:
>
> > These each return the assigned value of ptr (which may be NULL on
> > failure). For cases where the total size of the allocation is needed,
> > the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz() family
> > of ma
On Fri, 14 Mar 2025 at 17:15, Kees Cook wrote:
>
> Introduce type-aware kmalloc-family helpers to replace the common
> idioms for single, array, and flexible object allocations:
>
> kmalloc_obj(ptr, gfp);
> [ ... ]
Honestly, I absolutely hate this.
Don't do this. It's a huge mistake.
Ye
On 3/14/25 10:18 PM, Gustavo A. R. Silva wrote:
>
>> These each return the assigned value of ptr (which may be NULL on
>> failure). For cases where the total size of the allocation is needed,
>> the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz() family
>> of macros can be used. For
These each return the assigned value of ptr (which may be NULL on
failure). For cases where the total size of the allocation is needed,
the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz() family
of macros can be used. For example:
info->size = struct_size(ptr, flex_member, c
Introduce type-aware kmalloc-family helpers to replace the common
idioms for single, array, and flexible object allocations:
ptr = kmalloc(sizeof(*ptr), gfp);
ptr = kmalloc(sizeof(struct some_obj_name), gfp);
ptr = kzalloc(sizeof(*ptr), gfp);
ptr = kmalloc_array(cou