slab: Introduce kmalloc_obj() and family

Hi,

Here's a refresh and update on the kmalloc_obj() API proposal for discussion here and at LPC[1]. Please see patch 2 for the bulk of the details. And note that this is obviously not v6.19 material! :)

The tree-wide patch for conversions is here:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v6.18-rc6/alloc_obj/v5&id=f79ee96ad6a3cafdb274fe15d3ae067724e72327

Thanks!

-Kees

[1] https://lpc.events/event/19/contributions/2136/

v5:
- switch to using assignment with type as first argument (Linus)
- fix various comment, commit log, and kern-docs (Randy, Miguel)
- renamed flex_counter internal helpers with "__" prefix (Przemek)
v4: https://lore.kernel.org/lkml/[email protected]/
v3: https://lore.kernel.org/lkml/[email protected]/
v2: https://lore.kernel.org/lkml/[email protected]/
v1: https://lore.kernel.org/lkml/[email protected]/

Kees Cook (4):
compiler_types: Introduce __flex_counter() and family
slab: Introduce kmalloc_obj() and family
checkpatch: Suggest kmalloc_obj family for sizeof allocations
coccinelle: Add kmalloc_objs conversion script

 scripts/checkpatch.pl                     |  39 ++++-
 scripts/coccinelle/api/kmalloc_objs.cocci | 168 +++++++++++++++++++++
 Documentation/process/deprecated.rst      |  42 ++++++
 include/linux/compiler_types.h            |  31 ++++
 include/linux/overflow.h                  |  40 +++++
 include/linux/slab.h                      | 172 ++++++++++++++++++++++
 6 files changed, 486 insertions(+), 6 deletions(-)
 create mode 100644 scripts/coccinelle/api/kmalloc_objs.cocci

2.34.1

Introduce __flex_counter() which wraps __builtin_counted_by_ref(), as newly introduced by GCC[1] and Clang[2]. Use of __flex_counter() allows access to the counter member of a struct's flexible array member when it has been annotated with __counted_by().

Introduce typeof_flex_counter(), can_set_flex_counter(), and set_flex_counter() to provide the needed _Generic() wrappers to get sane results out of __flex_counter().

For example, with:

	struct foo {
		int counter;
		short array[] __counted_by(counter);
	} *p;

__flex_counter(p->array) will resolve to: &p->counter

typeof_flex_counter(p->array) will resolve to "int". (If p->array was not annotated, it would resolve to "size_t".)

can_set_flex_counter(p->array, COUNT) is the same as:

	COUNT <= type_max(p->counter) && COUNT >= type_min(p->counter)

(If p->array was not annotated it would return true since everything fits in size_t.)

set_flex_counter(p->array, COUNT) is the same as:

	p->counter = COUNT;

(It is a no-op if p->array is not annotated with __counted_by().)

---
Cc: Miguel Ojeda <[email protected]>
Cc: "Gustavo A. R. Silva" <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Marco Elver <[email protected]>
Cc: Przemek Kitszel <[email protected]>
Cc: [email protected]

---
 include/linux/compiler_types.h | 31 ++++++++++++++++++++++++++
 include/linux/overflow.h       | 40 ++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)

index c46855162a8a..a31fe3dbf576 100644
@@ -507,6 +507,37 @@ struct ftrace_likely_data {
 #define __annotated(var, attr)	__builtin_has_attribute(var, attr)
 #endif
 
+/*
+ * Optional: only supported since gcc >= 15, clang >= 19
+ *
+ *   gcc: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fcounted_005fby_005fref
+ * clang: https://clang.llvm.org/docs/LanguageExtensions.html#builtin-counted-by-ref
+ */
+#if __has_builtin(__builtin_counted_by_ref)
+/**
+ * __flex_counter() - Get pointer to counter member for the given
+ *                    flexible array, if it was annotated with __counted_by()
+ * @FAM: Pointer to flexible array member of an addressable struct instance
+ *
+ * For example, with:
+ *
+ *	struct foo {
+ *		int counter;
+ *		short array[] __counted_by(counter);
+ *	} *p;
+ *
+ * __flex_counter(p->array) will resolve to &p->counter.
+ *
+ * Note that Clang may not allow this to be assigned to a separate
+ * variable; it must be used directly.
+ *
+ * If p->array is unannotated, this returns (void *)NULL.
+ */
+#define __flex_counter(FAM)	__builtin_counted_by_ref(FAM)
+#else
+#define __flex_counter(FAM)	((void *)NULL)
+#endif
+
 /*
  * Some versions of gcc do not mark 'asm goto' volatile:
  *

index 725f95f7e416..12ca286c0f34 100644
@@ -540,4 +540,44 @@ static inline size_t __must_check size_sub(size_t minuend, size_t subtrahend)
 	(__member_size((name)->array) / sizeof(*(name)->array) +			\
 						__must_be_array((name)->array))
 
+/**
+ * typeof_flex_counter() - Return the type of the counter variable of a given
+ *                         flexible array member annotated by __counted_by().
+ * @FAM: Pointer to the flexible array member within a given struct.
+ *
+ * Returns: "size_t" if no annotation exists.
+ */
+#define typeof_flex_counter(FAM)				\
+	typeof(_Generic(__flex_counter(FAM),			\
+			void *: (size_t)0,			\
+			default: *__flex_counter(FAM)))
+
+/**
+ * __can_set_flex_counter() - Check if the counter associated with the given
+ *                            flexible array member can represent a value.
+ * @FAM: Pointer to the flexible array member within a given struct.
+ * @COUNT: Value to check against the __counted_by annotated @FAM's counter.
+ *
+ * Returns: true if @COUNT can be represented in the @FAM counter. When
+ * @FAM is not annotated with __counted_by(), always returns true.
+ */
+#define __can_set_flex_counter(FAM, COUNT)			\
+	(!overflows_type(COUNT, typeof_flex_counter(FAM)))
+
+/**
+ * __set_flex_counter() - Set the counter associated with the given flexible
+ *                        array member that has been annoated by __counted_by().
+ * @FAM: Pointer to the flexible array member within a given struct.
+ * @COUNT: Value to store to the __counted_by annotated @FAM's counter.
+ *
+ * This is a no-op if no annotation exists. Count needs to be checked with
+ * __can_set_flex_counter(@FAM, @COUNT) before using this function.
+ */
+#define __set_flex_counter(FAM, COUNT)				\
+({								\
+	*_Generic(__flex_counter(FAM),				\
+		  void *:  &(size_t){ 0 },			\
+		  default: __flex_counter(FAM)) = (COUNT);	\
+})
+
 #endif /* __LINUX_OVERFLOW_H */

2.34.1

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(count, sizeof(*ptr), gfp);
	ptr = kcalloc(count, sizeof(*ptr), gfp);
	ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);

These become, respectively:

	ptr = kmalloc_obj(*ptr, gfp);
	ptr = kmalloc_obj(*ptr, gfp);
	ptr = kzalloc_obj(*ptr, gfp);
	ptr = kmalloc_objs(*ptr, count, gfp);
	ptr = kzalloc_objs(*ptr, count, gfp);
	ptr = kmalloc_flex(*ptr, flex_member, count, gfp);

Beyond the other benefits outlined below, the primary ergonomic benefit is the elimination of needing "sizeof" nor the type name, and the enforcement of assignment types (they do not return "void *", but rather a pointer to the type of the first argument). The type name _can_ be used, though, in the case where an assignment is indirect (e.g. via "return").

These each return the newly allocated pointer to the type (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:

	size = struct_size(ptr, flex_member, count);
	ptr = kmalloc(size, gfp);

becomes:

	ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);

With the *_sz() helpers, it becomes possible to do bounds checking of the final size to make sure no arithmetic overflow has happened that exceeds the storage size of the target size variable. E.g. it was possible before to end up wrapping an allocation size and not noticing, there by allocating too small a size. (Most of Linux's exposure on that particular problem is via newly written code as we already did bulk conversions[1], but we continue to have a steady stream of patches catching additional cases[2] that would just go away with this API.)

Internal introspection of the allocated type now becomes possible, allowing for future alignment-aware choices to be made by the allocator and future hardening work that can be type sensitive. For example, adding __alignof(*ptr) as an argument to the internal allocators so that appropriate/efficient alignment choices can be made, or being able to correctly choose per-allocation offset randomization within a bucket that does not break alignment requirements.

For the flexible array helpers, the internal use of __flex_counter() allows for automatically setting the counter member of a struct's flexible array member when it has been annotated with __counted_by(), avoiding any missed early size initializations while __counted_by() annotations are added to the kernel. Additionally, this also checks for "too large" allocations based on the type size of the counter variable. For example:

	if (count > type_max(ptr->flex_count))
		fail...;
	size = struct_size(ptr, flex_member, count);
	ptr = kmalloc(size, gfp);
	ptr->flex_count = count;

becomes (n.b. unchanged from earlier example):

	ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);
	ptr->flex_count = count;

Note that manual initialization of the flexible array counter is still required (at some point) after allocation as not all compiler versions support the __counted_by annotation yet. But doing it internally makes sure they cannot be missed when __counted_by _is_ available, meaning that the bounds checker will not trip due to the lack of "early enough" initializations that used to work before enabling the stricter bounds checking. For example:

	ptr = kmalloc_flex(*ptr, flex_member, count);
	fill(ptr->flex, count);
	ptr->flex_count = count;

This works correctly before adding a __counted_by annotation (since nothing is checking ptr->flex accesses against ptr->flex_count). After adding the annotation, the bounds sanitizer would trip during fill() because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting ptr->flex_count internally at allocation time, the existing code works without needing to move the ptr->flex_count assignment before the call to fill(). (This has been a stumbling block for __counted_by adoption.)

Replacing all existing simple code patterns found via Coccinelle[3] shows what could be replaced immediately (also saving roughly 1000 lines):

 7863 files changed, 19639 insertions(+), 20692 deletions(-)

This would take us from 24085 k*alloc assignments to 7467:

$ git grep ' = kv\?[mzcv]alloc\(\|_array\)(' | wc -l
24085
$ git reset --hard HEAD^
HEAD is now at 8bccc91e6cdf treewide: kmalloc_obj conversion
$ git grep ' = kv\?[mzcv]alloc\(\|_array\)(' | wc -l
7467

This treewide change could be done at the end of the merge window just before -rc1 is released (as is common for treewide changes). Handling this API change in backports to -stable should be possible without much hassle by backporting the __flex_counter() patch and this patch, while taking conversions as-needed.

The impact on my bootable testing image size (with the treewide patch applied) is tiny. With both GCC 13 (no __counted_by support) and GCC 15 (with __counted_by) the images are actually very slightly smaller:

$ size -G gcc-boot/vmlinux.gcc*
      text       data        bss      total filename
  29975593   21527689   16601200   68104482 gcc-boot/vmlinux.gcc13-before
  29969263   21528663   16601112   68099038 gcc-boot/vmlinux.gcc13-after
  30555626   21291299   17086620   68933545 gcc-boot/vmlinux.gcc15-before
  30550144   21292039   17086540   68928723 gcc-boot/vmlinux.gcc15-after

---
Cc: Vlastimil Babka <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Roman Gushchin <[email protected]>
Cc: Hyeonggon Yoo <[email protected]>
Cc: Gustavo A. R. Silva <[email protected]>
Cc: Bill Wendling <[email protected]>
Cc: Justin Stitt <[email protected]>
Cc: Jann Horn <[email protected]>
Cc: Przemek Kitszel <[email protected]>
Cc: Marco Elver <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: [email protected]

---
 Documentation/process/deprecated.rst |  42 +++++++
 include/linux/slab.h                 | 172 +++++++++++++++++++++++++++
 2 files changed, 214 insertions(+)

index 1f7f3e6c9cda..eb72b75f5419 100644
@@ -372,3 +372,45 @@ The helper must be used::
 			DECLARE_FLEX_ARRAY(struct type2, two);
 		};
 	};
+
+Open-coded kmalloc assignments for struct objects
+-------------------------------------------------
+Performing open-coded kmalloc()-family allocation assignments prevents
+the kernel (and compiler) from being able to examine the type of the
+variable being assigned, which limits any related introspection that
+may help with alignment, wrap-around, or additional hardening. The
+kmalloc_obj()-family of macros provide this introspection, which can be
+used for the common code patterns for single, array, and flexible object
+allocations. For example, these open coded assignments::
+
+	ptr = kmalloc(sizeof(*ptr), gfp);
+	ptr = kmalloc(sizeof(struct the_type_of_ptr_obj), gfp);
+	ptr = kzalloc(sizeof(*ptr), gfp);
+	ptr = kmalloc_array(count, sizeof(*ptr), gfp);
+	ptr = kcalloc(count, sizeof(*ptr), gfp);
+	ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
+
+become, respectively::
+
+	ptr = kmalloc_obj(*ptr, gfp);
+	ptr = kzalloc_obj(*ptr, gfp);
+	ptr = kmalloc_objs(*ptr, count, gfp);
+	ptr = kzalloc_objs(*ptr, count, gfp);
+	ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
+
+For the cases where the total size of the allocation is also needed,
+the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz() family of
+macros can be used. For example, converting these assignments::
+
+	total_size = struct_size(ptr, flex_member, count);
+	ptr = kmalloc(total_size, gfp);
+
+becomes::
+
+	ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &total_size);
+
+If `ptr->flex_member` is annotated with __counted_by(), the allocation
+will automatically fail if `count` is larger than the maximum
+representable value that can be stored in the counter member associated
+with `flex_member`. Similarly, the allocation will fail if the total
+size of the allocation exceeds the maximum value `*total_size` can hold.

2.34.1

Honestly, I hate this.

In particular, I intensely dislike that horrendous 'SIZE' parameter to those helper macros, and this just needs to die.

The argument for that horror is also just silly:

That thing is ACTIVELY WORSE than the code it replaces.

One of them makes sense and is legible toi a normal human.

The other does not.

The alleged advantage is apparently that you can do it on one line, but when that one line is just horrible garbage, that is not an advantyage at all.

And the impact of that crazy SIZE on the macro expansions makes the whole thing entirely illegible.

I will not merge anything this broken.

The whole "limit to pre-defined size" argument is also just crazy, because now the SIZE parameter suddenly gets a second meaning. EVEN WORSE.

Finally, I think the parts of this that aren't wrong are too limited, and do not go far enough.

Because once you give that "alloc_obj()" an actual type, it should take the alignment of the type into account too.

I also think this part:

+ typeof(VAR) *__obj_ptr = NULL; \
+ if (!WARN_ON_ONCE(!__can_set_flex_counter(__obj_ptr->FAM, __count)) && \

absolutely needs to die. You just set __obj_ptr to NULL, and then you use __obj_ptr->FAM. Now, it so happens that __can_set_flex_counter() only cares about the *type*, but dammit, this kind of code sequence is simply not acceptable, and it needs to make that *explicit* by using sane syntax like perhaps just spelling that out, using VAR, not that NULL value.

IOW. making it use something like "typeof(VAR.FAM)" might work. Not that crazy garbage.

I never want to see this kind of horrendous patch again. Everything about it just screamed "disgusting".

Linus

Btw, I realize that we don't have a good way to do the alignment with the current kmalloc() interface (we do for some of the vmalloc interfaces).

So for now, it should just have some static build-time warning if the type of the object we allocate has a bigger alignment than the guaranteed slab allocation alignment (ARCH_KMALLOC_MINALIGN or whatever).

And I really think the first version should do the minimal thing that actually matters, and strive to deal with the simple cases. The main things that matter are

- the return type should be a proper pointer type (so that you get
warnings for mis-uses, but also so that you can use automatic typing)

- making the 'sizeof()' match the type

so honestly, I think 99% of the gain would come from something fairly simple like

    #define kmalloc_verify(type) \
        BUILD_BUG_ON_ZERO(__alignof__(type) > ARCH_KMALLOC_MINALIGN)

    #define kmalloc_size(type) \
        (sizeof(type) + kmalloc_verify(type))

    #define allocator(name, type, size, ...) \
        (typeof(type) *)name(size, __VA_ARGS__)

    #define kmalloc_obj(type, gfp) \
        allocator(kmalloc, type, kmalloc_size(type), gfp)
    #define kzalloc_obj(type, gfp) \
        allocator(kzalloc, type, kmalloc_size(type), gfp)
    #define kzalloc_struct(type, member, count, gfp) \
        allocator(kzalloc, type, struct_size_t(typeof(type), member,

count), gfp)

The above macros are entirely untested. But they are simple enough that even if they are buggy and I miscounted the parentheses or used the wrong name somewhere, I think the idea is clear. No?

(And I made that "allocator()" macro use __VA_ARGS__ because kzalloc_node() and friends would want that, but I think it's starting to hit diminishing returns at that point)

Hmm?

Linus

Note that these days we guarantee more than that, and it depends on size. From Documentation/core-api/memory-allocation.rst:

The address of a chunk allocated with kmalloc is aligned to at least ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the alignment is also guaranteed to be at least the respective size. For other sizes, the alignment is guaranteed to be at least the largest power-of-two divisor of the size.

So AFAIU this would be too pessimistic. I'm not sure if the alignment rules can be sensibly encoded in build time checks. Perhaps yes, in a similar way that we have compile-time size bucket selection via __kmalloc_index().

So I wouldn't worry about it over-much: it's actually pretty unusual that we have any odd alignment rules for anything that we would allocate with kmalloc.

And I don't think a 'kmalloc_obj()' case needs to necessarily *handle* such unusual cases, I just want this to be *detected*.

IOW, what I worry about would be people who use the simple object allocator mistakenly on auto-pilot.

So if it errors out about "you're trying to use the simple model for an object that requires non-simple alignment", that is perfectly fine. Those cases can - and do - use more specialized allocators.

Yes, yes, in a perfect world we'd just handle that case automatically, but it really is fairly rare, so forcing people to then use some more involved interface for those cases is maybe not optimal, but it's perfectly ok.

Linus

I extracted -- from your kind and loving feedback :) -- a number of specific concerns you seem to have about this proposal:

- You don't like the additional ..._sz set of helpers.
- Alignment isn't taken into account.
- You found the ...set_flex_counter() usage unreadable.

To me, it seems like the primary issue with this patch is that it probably needs to be at least 2 patches if not more, where we can iterate on each aspect.

The area of _agreement_, I think, is that type-based allocation is a good idea. You even recently used it as an example in an unrelated thread[1] discussing variable declarations in the middle of functions, and used (a form of) this API proposal, which I whole-heartedly agree with. i.e. that once we have type-based allocators, we can do things like:

  __auto_type var = alloc_obj(struct whatever, gfp);

So, taking each issue in turn...

(Size calculation)

The benefit is not that it is done in one line, but rather than the size calculations (which there is no exception handling for) gets built into the allocation so that wrapping and truncations get communicated back to the caller in the only way we have available: returning NULL from the allocation.

I'm not sure what you mean by "limit to pre-defined size". There's no such design in those helpers, except from the perspective of "detect and refuse to truncate overflows into too-small storage". Is that what you meant?

The persistent problem we have over and over in Linux is the lack of feedback from overflowed arithmetic. This is being worked on[2] at the same time, but I'm trying to find a way that we can get at "normal" error handling, since just exploding if an overflow happens isn't a very friendly way to deal with such conditions, but C doesn't give us much to work with. If it's _part_ of the allocation, though, we have a natural way to say "but you can't store 1024 into a u8".

For code like:

	u8 size;
	...
	size = struct_size(ptr, flex_member, count);
	ptr = kmalloc(size, gfp);

While struct_size() is designed to deal with overflows beyond SIZE_MAX, it can't do anything about truncation of its return value since it has no visibility into the lvalue type. So this code pattern happily truncates, allocates too little memory, and then usually does stuff like runs a for-loop based on "count" instead of "size" and walks right off the end of the heap allocation, clobbering whatever follows it.

If we have a clean way to build the size into the allocation, then we can report back a NULL allocation when something goes wrong with the calculation or the storage of the calculation.

Now, an alternative could be to keep the allocation and the size reporting separate with some kind of __must_check "give me the size of this thing" function, but I don't really like this because it feels much less ergonomic to me:

	u8 size;
	...
	__auto_type ptr = kmalloc_flex(struct whatever, counter, count, gfp);
	if (flex_size(ptr, counter, &size)) {
		kfree(ptr);
		return -EINVAL;
	}

(Alignment)

Sure, but that's the whole point of trying to switch to type-based
allocation: so that we CAN get at the alignment. That would be a "next step" approach in my mind, since we could bucketize allocations by type (or alignment), instead of by size. But that's more of a follow-on, in my opinion. I'd like to get some agreement on the exposed interface for this API first, and then move to enhancing the internals to take advantage of the new information.

(set_flex_counter)

I get your objection. We have other places where we do "((TYPE *)NULL)->member" explicitly to get at types, but I see what you mean that is feels very wrong to see the "->" after setting something to NULL in that it's separated from the NULL-ness.

One of the reasons for using __obj_ptr was because "VAR" may be a type and not a variable, so "VAR.FAM" isn't possible. Doing it the following way seemed uglier to me than using __obj_ptr->FAM:

	if (!WARN_ON_ONCE(!__can_set_flex_counter(((typeof(VAR) *)NULL)->FAM, __count)) &&

since we literally already have "((typeof(VAR) *)NULL)" with __obj_ptr.

But perhaps much of this could be collapsed into the __can_set_flex_counter() helper instead.

What do you think?

-Kees

[1] https://lore.kernel.org/all/CAHk-=wiCOTW5UftUrAnvJkr6769D29tF7Of79gUjdQHS_TkF5A@mail.gmail.com/
[2] https://github.com/llvm/llvm-project/pull/148914

Kees Cook

Have we investigated a compiler warning like -Wimplicit-arithmetic-truncation that would complain about this kind of thing and could be shut up by an explicit cast:

	size = (u8)struct_size(ptr, flex_member, count);

or arithmetic that can be proven to not overflow:

	size = struct_size(ptr, flex_member, count) & 0xff;

Maybe such a warning already exists and it's just too noisy to even start thinking about turning it on?

Yes, -Wconversion (W=3) is mind-blowingly noisy, unfortunately.

Kees Cook

It looks like GCC isn't smart enough. The first warning I saw was legit and easy to fix. The second one is bogus:

include/linux/err.h: In function ‘PTR_ERR_OR_ZERO’:
include/linux/err.h:120:24: error: conversion from ‘long int’ to ‘int’ may change value [-Werror=conversion]
120 | return PTR_ERR(ptr);

But GCC can prove that this isn't true; it just chooses not to:

#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)

static inline bool __must_check IS_ERR(__force const void *ptr)

{
        return IS_ERR_VALUE((unsigned long)ptr);
}

static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)

{
        if (IS_ERR(ptr))
                return PTR_ERR(ptr);

So GCC knows in this path that 'ptr' is in the range [-4095..-1] and the conversion from long to int will not change the value.

I imagine that fixing this is not high on the GCC developer priority list, but if we filed a bug that might change?

This third one is interesting.

include/linux/jump_label.h:126:44: error: conversion to ‘long unsigned int’ from ‘s32’ {aka ‘int’} may change the sign of the result [-Werror=sign-conversion]
126 | return (unsigned long)&entry->code + entry->code;

static inline unsigned long jump_entry_code(const struct jump_entry *entry)

{
        return (unsigned long)&entry->code + entry->code;
}

The warning is ... not the best phrased, but in terms of divining the programmer's intent, I genuinely don't know if this code is supposed to zero-extend or sign-extend the s32 to unsigned long. I know what it *does*, but I don't know if it was *supposed to do that*. So I wuold be in favour of enabling this warning ... if we have a small army of people on tap to get the kernel to build. There's 374 lines of errors to fix from the header files included by scripts/mod/devicetable-offsets.s alone.

This is my core frustration with C: we have SO many things where we have ambiguous intent. Yes, C may do exactly 1 thing with a given construct, but it isn't clear that the author's intent matches what actually happens.

I'm for it, but that is a LONG road. I have so many other hills to die on first. ;)

Kees Cook

Why?

I'm not seeing the confusion. 'entry->code' is a signed 32-bit entry, and we're adding it to the address of the entry itself (well, the address of the 'code' member of the entry, but it's the first thing in that struct, so same thing in this case).

The next function in that file (which uses "target", which is *not* the first entry in the struct) then makes it clear that we actually do all these relative offsets relative to the address of the relative offset itself, not the base address of the struct.

But that's actually just a random implementation decision.

That all a very standard thing in assembly programming, which this is all about. 'entry' is a signed offset from its own address.

And yes, the exact thing you are relative to may differ. When looking at instruction sets, sometimes the relative address is relative to the beginning of the current instruction (I think m68k did that), and sometimes it's relative to the *end* of the instruction (I think x86 does that). It could even be relative to the actual byte *inside* the instruction, although I can't think of an example of that.

Sometimes it's relative with a shift (basically all fixed-size instruction CPU's do that since instructions are all mutually aligned).

So that's whole "exactly what is it relative to, what are the sizes involved, and are there maybe shifts" etc just a design choice.

The whole "offset is relative to its own address" that this code uses is probably the simplest form it can have.

What?

A signed value gets sign-extended when cast to a larger type. That's how all of this always works. Casting a signed value to 'unsigned long' will set the high bits in the result.

That's pretty much the *definition* of a signed value. It gets sign-extended when used, and then obviously it becomes a large unsigned value, but this is how two's complement addition fundamentally works.

This is bog-standard and happens all over the place. We have things like

        unsigned long xyz = -1;

in various places, this is not some kind of unclear area of the standard.

And for all the same reasons, the programmers intent is obvious too. 'code' is s32 and is signed for a reason - so that you have a +-2GB relative offset. And this is not some kind of unusual pattern when we're talking about relative branch targets.

Now, if you don't know about things like relative branch targets in low-level assembly, maybe this is code you have to look over several times, but this code is literally ABOUT re-writing branches in assembly language, and this kind of pattern where you use relative offsets is traditional.

And yes, the offsets are literally smaller than the address space, and the signed offsets get sign-extended as part of this all: that's very traditional too.

Basically no 64-bit CPU has 64-bit branch offsets (and few 32-bit CPU's have full 32-bit branch offsets - x86 happens to do it, but most RISC CPU's tend to have branch offsets that are in the ~20 bit range and if you have big relative branches you need to do those with a separate constant section or something like that).

So honestly, what's the problem with this code?

The warning makes no sense, and is garbage. Are we not allowed to add signed integers to unsigned 64-bit values now, because that addition involves that cast of a signed 32-bit entry to an unsigned 64-bit one?

There is NO WAY that warning is valid, it's; not *ever* something we should enable, and the fact that you people are discussing it as such is just crazy.

That code would not be improved at all by adding another cast (to first cast that s32 to 'long', in order to then add it to 'unsigned long').

Imagine how many other places you add integers to 'unsigned long'. EVERY SINGLE ONE of those places involves sign-extending the integer and then doing arithmetic in unsigned.

Linus

I used to be an assembly programmer ... 28 years ago. I've mostly put that world out of my mind (and being able to write a 20,000 instruction ARM32 program entirely in assembly is just not that useful an accomplishment to put on my CV). Anyway, this isn't the point ...

Yes, agreed.

I have bad news. Rust requires it.

fn add(base: u64, off: i32) -> u64 {
base + off
}

error[E0308]: mismatched types
--> add.rs:2:12

  |
2 |     base + off
  |            ^^^ expected `u64`, found `i32`

error[E0277]: cannot add i32 to u64
--> add.rs:2:10

  |
2 |     base + off
  |          ^ no implementation for `u64 + i32`
  |
  = help: the trait `Add<i32>` is not implemented for `u64`
  = help: the following other types implement trait `Add<Rhs>`:
            <u64 as Add>
            <u64 as Add<&u64>>
            <&'a u64 as Add<u64>>
            <&u64 as Add<&u64>>

so the Rust language people have clearly decided that this is too complicated for your average programmer to figure out, and you need explicit casts to make it work.

Yup, and this is correct: "intent" becomes explicit. Doing implicit extension, narrowing, and truncation is just a mess. As part of the Overflow Behavior Type work, Justin has also been looking at something that would allow a typedef to not be allowed to be mixed with other types (i.e. to do so requires explicit casts). For example:

__strong typedef unsigned short only_u16;
...
only_u16 foo;
int bar = ...;
...
foo = bar; // Build failure: mismatched types
foo = (u16)bar; // okay, explicit truncation

-Kees

Kees Cook

Jeepers...
As I've found looking at min_t() you can't trust kernel programmers (never mind 'average' ones) to use the correct cast.
It wouldn't surprise be if the casts cause more bugs that the automatic conversions that C does.

It wouldn't be as bad if there were separate 'casts' for widening and narrowing. You also need the compiler to be doing 'value tracking' rather than just looking at the types.
If I do:

	int len = read(.....);
	if (len < 0)
		return -1;
	if (len > sizeof (...))
		...

then -Wsign-compare complains, but a statically_true(len >= 0) is fine.

David

...

Well, yes.

But the pain is front-loaded, so it's not like we have to go back and retrofit anything.

And I also want to tweak the characterization of that, below, because I suspect this is unevenly understood, so far:

A couple of key points, though:

a) There are many other, better options than casts (Rust's "as" keyword).

In fact, Rust doesn't actually require casts here, but it does require something to explicitly declare the programmer's intentions.

b) Rust doesn't do this because programmers are too dumb to figure it out. On the contrary, programmers are required to specify exactly what they want, in the first place.

Some examples, using Matthew's example as a starting point:

// u64 add operations:

//   +                          - panics on overflow (debug), wraps (release)
//   wrapping_add(u64)          - always wraps
//   wrapping_add_signed(i64)   - always wraps, accepts signed offset
//   checked_add(u64)           - returns Option, None on overflow
//   checked_add_signed(i64)    - returns Option, None on overflow
//   saturating_add(u64)        - clamps to u64::MAX
//   saturating_add_signed(i64) - clamps to 0 or u64::MAX
//   overflowing_add(u64)       - returns (result, bool)
//   overflowing_add_signed(i64)- returns (result, bool)
//   strict_add(u64)            - always panics on overflow (even release)
//   unchecked_add(u64)         - UB on overflow (unsafe, for optimization)
//   carrying_add(u64, bool)    - multi-word arithmetic, returns (result, carry)

// 1. Wrapping: overflow/underflow wraps around (address arithmetic)

fn add_wrapping(base: u64, off: i32) -> u64 {
    base.wrapping_add_signed(i64::from(off))
}

// 2. Checked: returns None on overflow/underflow

fn add_checked(base: u64, off: i32) -> Option<u64> {
    base.checked_add_signed(i64::from(off))
}

// 3. Saturating: clamps to 0 or u64::MAX

fn add_saturating(base: u64, off: i32) -> u64 {
    base.saturating_add_signed(i64::from(off))
}

// 4. Overflowing: returns (result, did_overflow)

fn add_overflowing(base: u64, off: i32) -> (u64, bool) {
    base.overflowing_add_signed(i64::from(off))
}

fn main() {
    let base: u64 = 0x100;
    let off: i32 = -0x200;

    println!("base=0x{:x}, off={} (underflow case)", base, off);
    println!("wrapping:    0x{:x}", add_wrapping(base, off));
    println!("checked:     {:?}", add_checked(base, off));
    println!("saturating:  0x{:x}", add_saturating(base, off));
    println!("overflowing: {:?}", add_overflowing(base, off));
}

// Output:
base=0x100, off=-512 (underflow case)

wrapping:    0xffffffffffffff00
checked:     None
saturating:  0x0
overflowing: (18446744073709551360, true)

thanks,

John Hubbard

I meant that odd combination of checking both for minimal size and then assigning to it, but upon re-reading it, I realize that the "check for minimal size" was actually checking the size of the result variable.

Those macros are illegible. And 99% of all users DO NOT WANT ANY OF THAT COMPLEXITY.

Yes, the wrapper macros then pass in NULL, which then - using yet more complexity - turns into a dummy thing.

Basically, if *I* find those macros unreadable - and I'm actually fairly good at parsing those things - then they are way too complicated.

And they aren't even complicated for a good reason. My alternate ones did *more*, and did it with less code and less confusion.

And you added the complication to make the users less legible.

So no. We're not doing *any* of that. You make it simple and targeted to the *common* case, of you don't do this at all. Because that over-designed mess that actually turned some users *less* readable, but one line shorter, was bad.

Linus

Okay, I think you're saying "I don't want the common helpers to include the infrastructure for supporting the ..._sz() variants"?

Fair enough. Looking at the treewide change I prepared[1], it's less than 1% of those mechanical replacements:

$ git show f79ee96ad6a3 | grep -E 'k.*alloc_(objs?|flex)\(' | wc -l
17473
$ git show f79ee96ad6a3 | grep '_sz(' | wc -l
114

I'll respin without the _sz variants, and try to improve the flex stuff.

-Kees

[1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v6.18-rc6/alloc_obj/v5

Kees Cook

I don't want the macros to expand the code more than necessary, because that just makes everything worse (including very much my build times - which have gotten worse over the years, but historically my build environment got faster at an even higher rate - that is no longer true).

I also want the macros to be somewhat understandable.

Yes, we have some macros that are works of art because they are *so* obscure and are fundamentally hard to understand because they play games with really really subtle language semantics.

And then I enjoy them and appreciate the insanity of them. I still think our __is_constexpr() macro is truly a wonder, but we do have 40 lines of comment (!) for that one strange macro.

But this was not *that* kind of hard-to-understand macro. This was just overly complicated.

Yeah, I did some numbers on my simple version, and just the three simple ones were the majority of cases by far.

I also believe that when we're doing more complicated size calculations (ie the whole "struct_size()" patterns), then the advantage of merging them with the allocation itself is questionable, simply because it takes two different pieces and makes them one *compilcated* piece.

Doing

        size = struct_size(ptr, flex_member, count);
        ptr = kmalloc(size, gfp);

is basically two fairly straightforward things and easy to understand. You can *scan* that code, and each piece is simple enough that it makes intuitive sense.

No, 'struct_size()' isn't exactly a very intuitive thing, but written that way it's also not very surprising or complicated to parse at a glance.

In contrast,

        ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);

does *not* make intuitive sense, I believe. Now you have five different arguments, and it's actually somewhat hard to parse, and there are odd semantics.

In contrast, the simple versions that take

        ptr = kmalloc(sizeof(*ptr), gfp);

and turn it into

        ptr = kmalloc_obj(*ptr, gfp);

actually become *simpler* to read and understand.

Yes, there are some other advantages to the combined version (ie that whole thing where 'kmalloc_obj()' now returns a proper _type_ - type safety is always good, and avoiding void pointers is a real thing), but I do think that the major advantage is "simpler to read".

Because in the end, simple code that does what you intuitively expect it to do, is good code, and hopefully less buggy.

Linus

what about below interface:

	ptr = kmalloc_flex(*ptr, member, count, gfp);
	size = kmalloc_flex_get_size(ptr);

so, users that don't care about size would not need to read or store it

but those that need the size (likely to pass the whole struct via some generic interface) will simply ask for it

note that there are some caveats, like user could add something like

	ptr->count++;

to destroy naive implementation for kmalloc_flex_get_size() above, but we don't need to make knee shooting any less painful

another note, there is ksize(), and if we would like to waste some more for actual size asked (as opposed to allocated), there could be a proper function (instead of the macro that will work only when user not messing with conventions) for kmalloc_flex_get_size()

To support shifting away from sized allocation towards typed allocations, suggest the kmalloc_obj family of macros when a sizeof() is present in the argument lists.

---
Cc: Andy Whitcroft <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Dwaipayan Ray <[email protected]>
Cc: Lukas Bulwahn <[email protected]>

---
 scripts/checkpatch.pl | 39 +++++++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 6 deletions(-)

index d58ca9655ab7..a8cdfb502ccc 100755
@@ -7258,17 +7258,42 @@ sub process {
 			    "Prefer $3(sizeof(*$1)...) over $3($4...)\n" . $herecurr);
 		}
 
-# check for (kv|k)[mz]alloc with multiplies that could be kmalloc_array/kvmalloc_array/kvcalloc/kcalloc
+# check for (kv|k)[mz]alloc that could be kmalloc_obj/kvmalloc_obj/kzalloc_obj/kvzalloc_obj
+		if ($perl_version_ok &&
+		    defined $stat &&
+		    $stat =~ /^\+\s*($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*,/) {
+			my $oldfunc = $3;
+			my $a1 = $4;
+			my $newfunc = "kmalloc_obj";
+			$newfunc = "kvmalloc_obj" if ($oldfunc eq "kvmalloc");
+			$newfunc = "kvzalloc_obj" if ($oldfunc eq "kvzalloc");
+			$newfunc = "kzalloc_obj" if ($oldfunc eq "kzalloc");
+
+			if ($a1 =~ s/^sizeof\s*\S\(?([^\)]*)\)?$/$1/) {
+				my $cnt = statement_rawlines($stat);
+				my $herectx = get_stat_here($linenr, $cnt, $here);
+
+				if (WARN("ALLOC_WITH_SIZEOF",
+					 "Prefer $newfunc over $oldfunc with sizeof\n" . $herectx) &&
+				    $cnt == 1 &&
+				    $fix) {
+					$fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*,/$1 = $newfunc($a1,/;
+				}
+			}
+		}
+
+
+# check for (kv|k)[mz]alloc with multiplies that could be kmalloc_objs/kvmalloc_objs/kzalloc_objs/kvzalloc_objs
 		if ($perl_version_ok &&
 		    defined $stat &&
 		    $stat =~ /^\+\s*($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)\s*,/) {
 			my $oldfunc = $3;
 			my $a1 = $4;
 			my $a2 = $10;
-			my $newfunc = "kmalloc_array";
-			$newfunc = "kvmalloc_array" if ($oldfunc eq "kvmalloc");
-			$newfunc = "kvcalloc" if ($oldfunc eq "kvzalloc");
-			$newfunc = "kcalloc" if ($oldfunc eq "kzalloc");
+			my $newfunc = "kmalloc_objs";
+			$newfunc = "kvmalloc_objs" if ($oldfunc eq "kvmalloc");
+			$newfunc = "kvzalloc_objs" if ($oldfunc eq "kvzalloc");
+			$newfunc = "kzalloc_objs" if ($oldfunc eq "kzalloc");
 			my $r1 = $a1;
 			my $r2 = $a2;
 			if ($a1 =~ /^sizeof\s*\S/) {

@@ -7284,7 +7309,9 @@ sub process {
 					 "Prefer $newfunc over $oldfunc with multiply\n" . $herectx) &&
 				    $cnt == 1 &&
 				    $fix) {
-					$fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . trim($r1) . ', ' . trim($r2)/e;
+					my $sized = trim($r2);
+					$sized =~ s/^sizeof\s*\S\(?([^\)]*)\)?$/$1/;
+					$fixed[$fixlinenr] =~ s/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k)[mz]alloc)\s*\(\s*($FuncArg)\s*\*\s*($FuncArg)/$1 . ' = ' . "$newfunc(" . $sized . ', ' . trim($r1)/e;
 				}
 			}
 		}

2.34.1

[]

The goal would be to also do the proposed treewide change which gets the vast majority of them converted.

Kees Cook

Finds and converts sized kmalloc-family of allocations into the typed kmalloc_obj-family of allocations.

---
Cc: Julia Lawall <[email protected]>
Cc: Nicolas Palix <[email protected]>
Cc: [email protected]

---
 scripts/coccinelle/api/kmalloc_objs.cocci | 168 ++++++++++++++++++++++
 1 file changed, 168 insertions(+)
 create mode 100644 scripts/coccinelle/api/kmalloc_objs.cocci

new file mode 100644
index 000000000000..39f82f014b17
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/// Use kmalloc_obj family of macros for allocations
+///
+// Confidence: High
+// Comments:
+// Options: --include-headers-for-types --all-includes --include-headers --keep-comments
+
+virtual patch
+
+@initialize:python@
+@@
+import sys
+
+def alloc_array(name):
+	func = "FAILED_RENAME"
+	if name == "kmalloc_array":
+		func = "kmalloc_objs"
+	elif name == "kvmalloc_array":
+		func = "kvmalloc_objs"
+	elif name == "kcalloc":
+		func = "kzalloc_objs"
+	elif name == "kvcalloc":
+		func = "kvzalloc_objs"
+	else:
+		print(f"Unknown transform for {name}", file=sys.stderr)
+	return func
+
+@assign_sizeof depends on patch && !(file in "tools") && !(file in "samples")@
+type TYPE;
+TYPE *P;
+TYPE INST;
+expression VAR;
+expression GFP;
+expression SIZE;
+identifier ALLOC =~ "^kv?[mz]alloc$";
+fresh identifier ALLOC_OBJ_SZ = ALLOC ## "_obj_sz";
+@@
+
+(
+-	SIZE = sizeof(*VAR);
+	... when != SIZE
+	VAR =
+-	ALLOC(SIZE, GFP);
++	ALLOC_OBJ_SZ(*VAR, GFP, &SIZE);
+|
+-	SIZE = (sizeof(TYPE));
+	... when != SIZE
+	P =
+-	ALLOC(SIZE, GFP);
++	ALLOC_OBJ_SZ(*P, GFP, &SIZE);
+|
+-	SIZE = (sizeof(INST));
+	... when != SIZE
+	P =
+-	ALLOC(SIZE, GFP);
++	ALLOC_OBJ_SZ(*P, GFP, &SIZE);
+)
+
+@assign_struct_size depends on patch && !(file in "tools") && !(file in "samples")@
+type TYPE;
+TYPE *P;
+expression VAR;
+expression GFP;
+expression SIZE;
+expression FLEX;
+expression COUNT;
+identifier ALLOC =~ "^kv?[mz]alloc$";
+fresh identifier ALLOC_FLEX_SZ = ALLOC ## "_flex_sz";
+@@
+
+(
+-	SIZE = struct_size(VAR, FLEX, COUNT);
+	... when != SIZE
+	VAR =
+-	ALLOC(SIZE, GFP);
++	ALLOC_FLEX_SZ(*VAR, FLEX, COUNT, GFP, &SIZE);
+|
+-	SIZE = struct_size_t(TYPE, FLEX, COUNT);
+	... when != SIZE
+	P =
+-	ALLOC(SIZE, GFP);
++	ALLOC_FLEX_SZ(*P, FLEX, COUNT, GFP, &SIZE);
+)
+
+// This excludes anything that is assigning to or from integral types or
+// string literals. Everything else gets the sizeof() extracted for the
+// kmalloc_obj() type/var argument. sizeof(void *) is also excluded because
+// it will need case-by-case double-checking to make sure the right type is
+// being assigned.
+@direct depends on patch && !(file in "tools") && !(file in "samples")@
+typedef u8, u16, u32, u64;
+typedef __u8, __u16, __u32, __u64;
+typedef uint8_t, uint16_t, uint32_t, uint64_t;
+typedef __le16, __le32, __le64;
+typedef __be16, __be32, __be64;
+type INTEGRAL = {u8,__u8,uint8_t,char,unsigned char,
+		 u16,__u16,uint16_t,unsigned short,
+		 u32,__u32,uint32_t,unsigned int,
+		 u64,__u64,uint64_t,unsigned long,
+		 __le16,__le32,__le64,__be16,__be32,__be64};
+char [] STRING;
+INTEGRAL *BYTES;
+type TYPE;
+expression VAR;
+expression GFP;
+expression COUNT;
+expression FLEX;
+expression E;
+identifier ALLOC =~ "^kv?[mz]alloc$";
+fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
+fresh identifier ALLOC_FLEX = ALLOC ## "_flex";
+identifier ALLOC_ARRAY = {kmalloc_array,kvmalloc_array,kcalloc,kvcalloc};
+fresh identifier ALLOC_OBJS = script:python(ALLOC_ARRAY) { alloc_array(ALLOC_ARRAY) };
+@@
+
+(
+-	VAR = ALLOC((sizeof(*VAR)), GFP)
++	VAR = ALLOC_OBJ(*VAR, GFP)
+|
+	ALLOC((\(sizeof(STRING)\|sizeof(INTEGRAL)\|sizeof(INTEGRAL *)\)), GFP)
+|
+	BYTES = ALLOC((sizeof(E)), GFP)
+|
+	BYTES = ALLOC((sizeof(TYPE)), GFP)
+|
+	ALLOC((sizeof(void *)), GFP)
+|
+-	ALLOC((sizeof(E)), GFP)
++	ALLOC_OBJ(E, GFP)
+|
+-	ALLOC((sizeof(TYPE)), GFP)
++	ALLOC_OBJ(TYPE, GFP)
+|
+	ALLOC_ARRAY(COUNT, (\(sizeof(STRING)\|sizeof(INTEGRAL)\|sizeof(INTEGRAL *)\)), GFP)
+|
+	BYTES = ALLOC_ARRAY(COUNT, (sizeof(E)), GFP)
+|
+	BYTES = ALLOC_ARRAY(COUNT, (sizeof(TYPE)), GFP)
+|
+	ALLOC_ARRAY((\(sizeof(STRING)\|sizeof(INTEGRAL)\|sizeof(INTEGRAL *)\)), COUNT, GFP)
+|
+	BYTES = ALLOC_ARRAY((sizeof(E)), COUNT, GFP)
+|
+	BYTES = ALLOC_ARRAY((sizeof(TYPE)), COUNT, GFP)
+|
+	ALLOC_ARRAY(COUNT, (sizeof(void *)), GFP)
+|
+	ALLOC_ARRAY((sizeof(void *)), COUNT, GFP)
+|
+-	ALLOC_ARRAY(COUNT, (sizeof(E)), GFP)
++	ALLOC_OBJS(E, COUNT, GFP)
+|
+-	ALLOC_ARRAY(COUNT, (sizeof(TYPE)), GFP)
++	ALLOC_OBJS(TYPE, COUNT, GFP)
+|
+-	ALLOC_ARRAY((sizeof(E)), COUNT, GFP)
++	ALLOC_OBJS(E, COUNT, GFP)
+|
+-	ALLOC_ARRAY((sizeof(TYPE)), COUNT, GFP)
++	ALLOC_OBJS(TYPE, COUNT, GFP)
+|
+-	ALLOC(struct_size(VAR, FLEX, COUNT), GFP)
++	ALLOC_FLEX(*VAR, FLEX, COUNT, GFP)
+|
+-	ALLOC(struct_size_t(TYPE, FLEX, COUNT), GFP)
++	ALLOC_FLEX(TYPE, FLEX, COUNT, GFP)
+)
+

2.34.1

See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.18-rc7#n94

…

…

…

* Please omit such an empty information line.

* Would a field like “Keywords” become helpful?

Will additional operation modes become relevant after clarification of implementation details?

…

"Describe your changes in imperative mood"

I guess I can try rewording this, but it is describing the behavior of the script. Normally the imperative language for a patch is about what the patch accomplishes. In this case, I've added a script and it does a thing itself.

Agreed; I removed this in v5.

I only see a few using this -- what benefit is there to adding it? It seems redundant to the rest of the file, its opening comment, etc.

I am not interested in other modes; if people want to contribute them, they are welcome. :)

I wanted the stderr warning when there was no match, but to return "FAILED_RENAME" in such a case. Using a dictionary was basically the same length as the elif stack. If you have an alternative, I'm happy to replace it with what you come up with.

That is true, but I like having them separated -- I find it more readable that way.

Kees Cook

I became curious once more how another improved change descrition can look like.

Will development interests eventually grow accordingly?

Such a data processing result can be achieved also by a more appropriate algorithm, can't it?

Is there a need for further case distinctions?

Under which circumstances would you become used also to more succinct SmPL code?

Regards,
Markus