* [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family
@ 2026-04-29 7:08 Manuel Ebner
2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Manuel Ebner @ 2026-04-29 7:08 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook
Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm,
Manuel Ebner
Update the documentation to reflect new type-aware kmalloc-family as
suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj()
and family")
[v3] -> [v4]:
state the default argument in deprecated.rst [3/3]
[v2] -> [v3]:
remove obvious wrong replacements in [1/3]
add Acked-by: Paul E. McKenney in [2/3]
change how to mark the optional argument in [3/3]
add recipants
--cc="linux-mm@kvack.org"
--to="Kees Cook"
--cc="Geert Uytterhoeven"
[v1] -> [v2]:
put RCU/* in a seperate patch [Patch 2/3]
Omit optional argument (GFP_KERNEL) as suggested by https://lwn.net/Articles/1062856/
deprecated.rst: change the argument gfp to optional [Patch 3/3]
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH v4 1/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-29 7:08 [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Manuel Ebner @ 2026-04-29 7:14 ` Manuel Ebner 2026-04-29 8:00 ` Vlastimil Babka 2026-04-30 0:53 ` SeongJae Park 2026-04-29 7:27 ` [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional Manuel Ebner 2026-05-03 14:56 ` [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Jonathan Corbet 2 siblings, 2 replies; 13+ messages in thread From: Manuel Ebner @ 2026-04-29 7:14 UTC (permalink / raw) To: Jonathan Corbet, Shuah Khan, linux-doc Cc: Kees Cook, linux-kernel, workflows, linux-sound, linux-media, linux-mm, Manuel Ebner Update the documentation to reflect new type-aware kmalloc-family as suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family") ptr = kmalloc(sizeof(*ptr), gfp); -> ptr = kmalloc_obj(*ptr); ptr = kmalloc(sizeof(struct some_obj_name), gfp); -> ptr = kmalloc_obj(*ptr); ptr = kzalloc(sizeof(*ptr), gfp); -> ptr = kzalloc_obj(*ptr); ptr = kmalloc_array(count, sizeof(*ptr), gfp); -> ptr = kmalloc_objs(*ptr, count); ptr = kcalloc(count, sizeof(*ptr), gfp); -> ptr = kzalloc_objs(*ptr, count); Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> --- Documentation/core-api/kref.rst | 4 ++-- Documentation/core-api/list.rst | 4 ++-- Documentation/driver-api/mailbox.rst | 4 ++-- Documentation/driver-api/media/v4l2-fh.rst | 2 +- Documentation/kernel-hacking/locking.rst | 4 ++-- Documentation/locking/locktypes.rst | 4 ++-- Documentation/process/coding-style.rst | 8 ++++---- .../sound/kernel-api/writing-an-alsa-driver.rst | 12 ++++++------ Documentation/spi/spi-summary.rst | 4 ++-- .../translations/it_IT/kernel-hacking/locking.rst | 4 ++-- .../translations/it_IT/locking/locktypes.rst | 4 ++-- .../translations/it_IT/process/coding-style.rst | 2 +- .../translations/sp_SP/process/coding-style.rst | 2 +- Documentation/translations/zh_CN/core-api/kref.rst | 4 ++-- .../translations/zh_CN/process/coding-style.rst | 2 +- .../zh_CN/video4linux/v4l2-framework.txt | 2 +- .../translations/zh_TW/process/coding-style.rst | 2 +- 18 files changed, 36 insertions(+), 36 deletions(-) diff --git a/Documentation/core-api/kref.rst b/Documentation/core-api/kref.rst index 8db9ff03d952..1c14c036699d 100644 --- a/Documentation/core-api/kref.rst +++ b/Documentation/core-api/kref.rst @@ -40,7 +40,7 @@ kref_init as so:: struct my_data *data; - data = kmalloc(sizeof(*data), GFP_KERNEL); + data = kmalloc_obj(*data); if (!data) return -ENOMEM; kref_init(&data->refcount); @@ -100,7 +100,7 @@ thread to process:: int rv = 0; struct my_data *data; struct task_struct *task; - data = kmalloc(sizeof(*data), GFP_KERNEL); + data = kmalloc_obj(*data); if (!data) return -ENOMEM; kref_init(&data->refcount); diff --git a/Documentation/core-api/list.rst b/Documentation/core-api/list.rst index 241464ca0549..86cd0a1b77ea 100644 --- a/Documentation/core-api/list.rst +++ b/Documentation/core-api/list.rst @@ -112,7 +112,7 @@ list: /* State 1 */ - grock = kzalloc(sizeof(*grock), GFP_KERNEL); + grock = kzalloc_obj(*grock); if (!grock) return -ENOMEM; grock->name = "Grock"; @@ -123,7 +123,7 @@ list: /* State 2 */ - dimitri = kzalloc(sizeof(*dimitri), GFP_KERNEL); + dimitri = kzalloc_obj(*dimitri); if (!dimitri) return -ENOMEM; dimitri->name = "Dimitri"; diff --git a/Documentation/driver-api/mailbox.rst b/Documentation/driver-api/mailbox.rst index 463dd032b96c..4bcd73a99115 100644 --- a/Documentation/driver-api/mailbox.rst +++ b/Documentation/driver-api/mailbox.rst @@ -87,8 +87,8 @@ a message and a callback function to the API and return immediately). struct async_pkt ap; struct sync_pkt sp; - dc_sync = kzalloc(sizeof(*dc_sync), GFP_KERNEL); - dc_async = kzalloc(sizeof(*dc_async), GFP_KERNEL); + dc_sync = kzalloc_obj(*dc_sync); + dc_async = kzalloc_obj(*dc_async); /* Populate non-blocking mode client */ dc_async->cl.dev = &pdev->dev; diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst index a934caa483a4..38319130ebf5 100644 --- a/Documentation/driver-api/media/v4l2-fh.rst +++ b/Documentation/driver-api/media/v4l2-fh.rst @@ -42,7 +42,7 @@ Example: ... - my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); + my_fh = kzalloc_obj(*my_fh); ... diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index dff0646a717b..d02e62367c4f 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -442,7 +442,7 @@ to protect the cache and all the objects within it. Here's the code:: { struct object *obj; - if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL) + if ((obj = kmalloc_obj(*obj)) == NULL) return -ENOMEM; strscpy(obj->name, name, sizeof(obj->name)); @@ -517,7 +517,7 @@ which are taken away, and the ``+`` are lines which are added. struct object *obj; + unsigned long flags; - if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL) + if ((obj = kmalloc_obj(*obj)) == NULL) return -ENOMEM; @@ -63,30 +64,33 @@ obj->id = id; diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index 37b6a5670c2f..ac1ad722a9e7 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -498,7 +498,7 @@ allocating memory. Thus, on a non-PREEMPT_RT kernel the following code works perfectly:: raw_spin_lock(&lock); - p = kmalloc(sizeof(*p), GFP_ATOMIC); + p = kmalloc_obj(*p, GFP_ATOMIC); But this code fails on PREEMPT_RT kernels because the memory allocator is fully preemptible and therefore cannot be invoked from truly atomic @@ -507,7 +507,7 @@ while holding normal non-raw spinlocks because they do not disable preemption on PREEMPT_RT kernels:: spin_lock(&lock); - p = kmalloc(sizeof(*p), GFP_ATOMIC); + p = kmalloc_obj(*p, GFP_ATOMIC); bit spinlocks diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 35b381230f6e..a3bf75dc7c88 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -936,7 +936,7 @@ used. --------------------- The kernel provides the following general purpose memory allocators: -kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and +kmalloc(), kzalloc(), kmalloc_objs(), kzalloc_objs(), vmalloc(), and vzalloc(). Please refer to the API documentation for further information about them. :ref:`Documentation/core-api/memory-allocation.rst <memory_allocation>` @@ -945,7 +945,7 @@ The preferred form for passing a size of a struct is the following: .. code-block:: c - p = kmalloc(sizeof(*p), ...); + p = kmalloc_obj(*p, ...); The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed @@ -959,13 +959,13 @@ The preferred form for allocating an array is the following: .. code-block:: c - p = kmalloc_array(n, sizeof(...), ...); + p = kmalloc_objs(*ptr, n, ...); The preferred form for allocating a zeroed array is the following: .. code-block:: c - p = kcalloc(n, sizeof(...), ...); + p = kzalloc_objs(*ptr, n, ...); Both forms check for overflow on the allocation size n * sizeof(...), and return NULL if that occurred. diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 895752cbcedd..12433612aa9c 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -266,7 +266,7 @@ to details explained in the following section. .... /* allocate a chip-specific data with zero filled */ - chip = kzalloc(sizeof(*chip), GFP_KERNEL); + chip = kzalloc_obj(*chip); if (chip == NULL) return -ENOMEM; @@ -628,7 +628,7 @@ After allocating a card instance via :c:func:`snd_card_new()` err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, 0, &card); ..... - chip = kzalloc(sizeof(*chip), GFP_KERNEL); + chip = kzalloc_obj(*chip); The chip record should have the field to hold the card pointer at least, @@ -747,7 +747,7 @@ destructor and PCI entries. Example code is shown first, below:: return -ENXIO; } - chip = kzalloc(sizeof(*chip), GFP_KERNEL); + chip = kzalloc_obj(*chip); if (chip == NULL) { pci_disable_device(pci); return -ENOMEM; @@ -1737,7 +1737,7 @@ callback:: { struct my_pcm_data *data; .... - data = kmalloc(sizeof(*data), GFP_KERNEL); + data = kmalloc_obj(*data); substream->runtime->private_data = data; .... } @@ -3301,7 +3301,7 @@ You can then pass any pointer value to the ``private_data``. If you assign private data, you should define a destructor, too. The destructor function is set in the ``private_free`` field:: - struct mydata *p = kmalloc(sizeof(*p), GFP_KERNEL); + struct mydata *p = kmalloc_obj(*p); hw->private_data = p; hw->private_free = mydata_free; @@ -3833,7 +3833,7 @@ chip data individually:: err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, 0, &card); .... - chip = kzalloc(sizeof(*chip), GFP_KERNEL); + chip = kzalloc_obj(*chip); .... card->private_data = chip; .... diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst index 6e21e6f86912..7ad6af76c247 100644 --- a/Documentation/spi/spi-summary.rst +++ b/Documentation/spi/spi-summary.rst @@ -249,7 +249,7 @@ And SOC-specific utility code might look something like:: { struct mysoc_spi_data *pdata2; - pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL); + pdata2 = kmalloc_obj(*pdata2); *pdata2 = pdata; ... if (n == 2) { @@ -373,7 +373,7 @@ a bus (appearing under /sys/class/spi_master). return -ENODEV; /* get memory for driver's per-chip state */ - chip = kzalloc(sizeof *chip, GFP_KERNEL); + chip = kzalloc(*chip); if (!chip) return -ENOMEM; spi_set_drvdata(spi, chip); diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 4c21cf60f775..acca89a3743a 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -462,7 +462,7 @@ e tutti gli oggetti che contiene. Ecco il codice:: { struct object *obj; - if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL) + if ((obj = kmalloc_obj(*obj)) == NULL) return -ENOMEM; strscpy(obj->name, name, sizeof(obj->name)); @@ -537,7 +537,7 @@ sono quelle rimosse, mentre quelle ``+`` sono quelle aggiunte. struct object *obj; + unsigned long flags; - if ((obj = kmalloc(sizeof(*obj), GFP_KERNEL)) == NULL) + if ((obj = kmalloc_obj(*obj)) == NULL) return -ENOMEM; @@ -63,30 +64,33 @@ obj->id = id; diff --git a/Documentation/translations/it_IT/locking/locktypes.rst b/Documentation/translations/it_IT/locking/locktypes.rst index 1c7056283b9d..d5fa36aa05cc 100644 --- a/Documentation/translations/it_IT/locking/locktypes.rst +++ b/Documentation/translations/it_IT/locking/locktypes.rst @@ -488,7 +488,7 @@ o rwlock_t. Per esempio, la sezione critica non deve fare allocazioni di memoria. Su un kernel non-PREEMPT_RT il seguente codice funziona perfettamente:: raw_spin_lock(&lock); - p = kmalloc(sizeof(*p), GFP_ATOMIC); + p = kmalloc_obj(*p, GFP_ATOMIC); Ma lo stesso codice non funziona su un kernel PREEMPT_RT perché l'allocatore di memoria può essere oggetto di prelazione e quindi non può essere chiamato in un @@ -497,7 +497,7 @@ trattiene un blocco *non-raw* perché non disabilitano la prelazione sui kernel PREEMPT_RT:: spin_lock(&lock); - p = kmalloc(sizeof(*p), GFP_ATOMIC); + p = kmalloc_obj(*p, GFP_ATOMIC); bit spinlocks diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index c0dc786b8474..2a499412a2e3 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -943,7 +943,7 @@ Il modo preferito per passare la dimensione di una struttura è il seguente: .. code-block:: c - p = kmalloc(sizeof(*p), ...); + p = kmalloc_obj(*p, ...); La forma alternativa, dove il nome della struttura viene scritto interamente, peggiora la leggibilità e introduce possibili bachi quando il tipo di diff --git a/Documentation/translations/sp_SP/process/coding-style.rst b/Documentation/translations/sp_SP/process/coding-style.rst index 7d63aa8426e6..44c93d5f6beb 100644 --- a/Documentation/translations/sp_SP/process/coding-style.rst +++ b/Documentation/translations/sp_SP/process/coding-style.rst @@ -955,7 +955,7 @@ La forma preferida para pasar el tamaño de una estructura es la siguiente: .. code-block:: c - p = kmalloc(sizeof(*p), ...); + p = kmalloc_obj(*p, ...); La forma alternativa donde se deletrea el nombre de la estructura perjudica la legibilidad, y presenta una oportunidad para un error cuando se cambia diff --git a/Documentation/translations/zh_CN/core-api/kref.rst b/Documentation/translations/zh_CN/core-api/kref.rst index b9902af310c5..fcff01e99852 100644 --- a/Documentation/translations/zh_CN/core-api/kref.rst +++ b/Documentation/translations/zh_CN/core-api/kref.rst @@ -52,7 +52,7 @@ kref可以出现在数据结构体中的任何地方。 struct my_data *data; - data = kmalloc(sizeof(*data), GFP_KERNEL); + data = kmalloc_obj(*data); if (!data) return -ENOMEM; kref_init(&data->refcount); @@ -106,7 +106,7 @@ Kref规则 int rv = 0; struct my_data *data; struct task_struct *task; - data = kmalloc(sizeof(*data), GFP_KERNEL); + data = kmalloc_obj(*data); if (!data) return -ENOMEM; kref_init(&data->refcount); diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index 5a342a024c01..55d5da974d89 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -813,7 +813,7 @@ Documentation/translations/zh_CN/core-api/memory-allocation.rst 。 .. code-block:: c - p = kmalloc(sizeof(*p), ...); + p = kmalloc_obj(*p, ...); 另外一种传递方式中，sizeof 的操作数是结构体的名字，这样会降低可读性，并且可能 会引入 bug。有可能指针变量类型被改变时，而对应的传递给内存分配函数的 sizeof diff --git a/Documentation/translations/zh_CN/video4linux/v4l2-framework.txt b/Documentation/translations/zh_CN/video4linux/v4l2-framework.txt index f0be21a60a0f..ba43c5c4797c 100644 --- a/Documentation/translations/zh_CN/video4linux/v4l2-framework.txt +++ b/Documentation/translations/zh_CN/video4linux/v4l2-framework.txt @@ -799,7 +799,7 @@ int my_open(struct file *file) ... - my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); + my_fh = kzalloc_obj(*my_fh); ... diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst index e2ba97b3d8bb..63c78982a1af 100644 --- a/Documentation/translations/zh_TW/process/coding-style.rst +++ b/Documentation/translations/zh_TW/process/coding-style.rst @@ -827,7 +827,7 @@ Documentation/translations/zh_CN/core-api/memory-allocation.rst 。 .. code-block:: c - p = kmalloc(sizeof(*p), ...); + p = kmalloc_obj(*p, ...); 另外一種傳遞方式中，sizeof 的操作數是結構體的名字，這樣會降低可讀性，並且可能 會引入 bug。有可能指針變量類型被改變時，而對應的傳遞給內存分配函數的 sizeof -- 2.53.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v4 1/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner @ 2026-04-29 8:00 ` Vlastimil Babka 2026-04-30 0:53 ` SeongJae Park 1 sibling, 0 replies; 13+ messages in thread From: Vlastimil Babka @ 2026-04-29 8:00 UTC (permalink / raw) To: Manuel Ebner, Jonathan Corbet, Shuah Khan, linux-doc Cc: Kees Cook, linux-kernel, workflows, linux-sound, linux-media, linux-mm On 4/29/26 09:14, Manuel Ebner wrote: > Update the documentation to reflect new type-aware kmalloc-family as > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > and family") > > ptr = kmalloc(sizeof(*ptr), gfp); > -> ptr = kmalloc_obj(*ptr); > ptr = kmalloc(sizeof(struct some_obj_name), gfp); > -> ptr = kmalloc_obj(*ptr); > ptr = kzalloc(sizeof(*ptr), gfp); > -> ptr = kzalloc_obj(*ptr); > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > -> ptr = kmalloc_objs(*ptr, count); > ptr = kcalloc(count, sizeof(*ptr), gfp); > -> ptr = kzalloc_objs(*ptr, count); > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 1/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner 2026-04-29 8:00 ` Vlastimil Babka @ 2026-04-30 0:53 ` SeongJae Park 2026-04-30 1:00 ` SeongJae Park 1 sibling, 1 reply; 13+ messages in thread From: SeongJae Park @ 2026-04-30 0:53 UTC (permalink / raw) To: Manuel Ebner Cc: SeongJae Park, Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel, workflows, linux-sound, linux-media, linux-mm On Wed, 29 Apr 2026 09:14:44 +0200 Manuel Ebner <manuelebner@mailbox.org> wrote: > Update the documentation to reflect new type-aware kmalloc-family as > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > and family") > > ptr = kmalloc(sizeof(*ptr), gfp); > -> ptr = kmalloc_obj(*ptr); > ptr = kmalloc(sizeof(struct some_obj_name), gfp); > -> ptr = kmalloc_obj(*ptr); > ptr = kzalloc(sizeof(*ptr), gfp); > -> ptr = kzalloc_obj(*ptr); > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > -> ptr = kmalloc_objs(*ptr, count); > ptr = kcalloc(count, sizeof(*ptr), gfp); > -> ptr = kzalloc_objs(*ptr, count); > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Acked-by: SeongJae Park <sj@kernel.org> Thanks, SJ [...] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 1/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-30 0:53 ` SeongJae Park @ 2026-04-30 1:00 ` SeongJae Park 2026-05-01 9:12 ` Manuel Ebner 0 siblings, 1 reply; 13+ messages in thread From: SeongJae Park @ 2026-04-30 1:00 UTC (permalink / raw) To: SeongJae Park Cc: Manuel Ebner, Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel, workflows, linux-sound, linux-media, linux-mm On Wed, 29 Apr 2026 17:53:36 -0700 SeongJae Park <sj@kernel.org> wrote: > On Wed, 29 Apr 2026 09:14:44 +0200 Manuel Ebner <manuelebner@mailbox.org> wrote: > > > Update the documentation to reflect new type-aware kmalloc-family as > > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > > and family") > > > > ptr = kmalloc(sizeof(*ptr), gfp); > > -> ptr = kmalloc_obj(*ptr); > > ptr = kmalloc(sizeof(struct some_obj_name), gfp); > > -> ptr = kmalloc_obj(*ptr); > > ptr = kzalloc(sizeof(*ptr), gfp); > > -> ptr = kzalloc_obj(*ptr); > > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > > -> ptr = kmalloc_objs(*ptr, count); > > ptr = kcalloc(count, sizeof(*ptr), gfp); > > -> ptr = kzalloc_objs(*ptr, count); Forgot asking this, sorry. Shouldn't 'gfp' parameters be kept? > > > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> > > Acked-by: SeongJae Park <sj@kernel.org> My Acked-by: is still valid regardless of your answer to my trivial question. Thanks, SJ [...] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 1/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-30 1:00 ` SeongJae Park @ 2026-05-01 9:12 ` Manuel Ebner 0 siblings, 0 replies; 13+ messages in thread From: Manuel Ebner @ 2026-05-01 9:12 UTC (permalink / raw) To: SeongJae Park Cc: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel, workflows, linux-sound, linux-media, linux-mm On Wed, 2026-04-29 at 18:00 -0700, SeongJae Park wrote: > On Wed, 29 Apr 2026 17:53:36 -0700 SeongJae Park <sj@kernel.org> wrote: > > > On Wed, 29 Apr 2026 09:14:44 +0200 Manuel Ebner <manuelebner@mailbox.org> > > wrote: > > > > > Update the documentation to reflect new type-aware kmalloc-family as > > > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > > > and family") > > > > > > ptr = kmalloc(sizeof(*ptr), gfp); > > > -> ptr = kmalloc_obj(*ptr); > > > ptr = kmalloc(sizeof(struct some_obj_name), gfp); > > > -> ptr = kmalloc_obj(*ptr); > > > ptr = kzalloc(sizeof(*ptr), gfp); > > > -> ptr = kzalloc_obj(*ptr); > > > ptr = kmalloc_array(count, sizeof(*ptr), gfp); > > > -> ptr = kmalloc_objs(*ptr, count); > > > ptr = kcalloc(count, sizeof(*ptr), gfp); > > > -> ptr = kzalloc_objs(*ptr, count); > > Forgot asking this, sorry. Shouldn't 'gfp' parameters be kept? Yes, i should have kept it, like so: eg. ptr = kmalloc_obj(*ptr, gfp); -> ptr = kmalloc_obj(*ptr [, gfp] ); same in [Patch 2/3] > > > > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> > > > > Acked-by: SeongJae Park <sj@kernel.org> > > My Acked-by: is still valid regardless of your answer to my trivial question. Thanks Manuel > > Thanks, > SJ > > [...] ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional 2026-04-29 7:08 [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Manuel Ebner 2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner @ 2026-04-29 7:27 ` Manuel Ebner 2026-04-29 8:01 ` Vlastimil Babka 2026-04-30 1:03 ` SeongJae Park 2026-05-03 14:56 ` [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Jonathan Corbet 2 siblings, 2 replies; 13+ messages in thread From: Manuel Ebner @ 2026-04-29 7:27 UTC (permalink / raw) To: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel Cc: workflows, linux-mm, Geert Uytterhoeven, Manuel Ebner put the optional argument (gfp) in square brackets add default value = GFP_KERNEL eg. ptr = kmalloc_obj(*ptr, gfp); -> ptr = kmalloc_obj(*ptr [, gfp] ); Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> --- Documentation/process/deprecated.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index fed56864d036..ac75b7ecac47 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -392,13 +392,14 @@ allocations. For example, these open coded assignments:: 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); - __auto_type ptr = kmalloc_obj(struct foo, 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] ); + __auto_type ptr = kmalloc_obj(struct foo [, gfp] ); + +The argument gfp is optional, the default value is GFP_KERNEL. 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 -- 2.53.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional 2026-04-29 7:27 ` [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional Manuel Ebner @ 2026-04-29 8:01 ` Vlastimil Babka 2026-04-30 1:03 ` SeongJae Park 1 sibling, 0 replies; 13+ messages in thread From: Vlastimil Babka @ 2026-04-29 8:01 UTC (permalink / raw) To: Manuel Ebner, Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel Cc: workflows, linux-mm, Geert Uytterhoeven On 4/29/26 09:27, Manuel Ebner wrote: > put the optional argument (gfp) in square brackets > add default value = GFP_KERNEL > > eg. ptr = kmalloc_obj(*ptr, gfp); > -> ptr = kmalloc_obj(*ptr [, gfp] ); > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> > --- > Documentation/process/deprecated.rst | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst > index fed56864d036..ac75b7ecac47 100644 > --- a/Documentation/process/deprecated.rst > +++ b/Documentation/process/deprecated.rst > @@ -392,13 +392,14 @@ allocations. For example, these open coded assignments:: > > 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); > - __auto_type ptr = kmalloc_obj(struct foo, 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] ); > + __auto_type ptr = kmalloc_obj(struct foo [, gfp] ); > + > +The argument gfp is optional, the default value is GFP_KERNEL. > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional 2026-04-29 7:27 ` [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional Manuel Ebner 2026-04-29 8:01 ` Vlastimil Babka @ 2026-04-30 1:03 ` SeongJae Park 2026-05-01 9:19 ` Manuel Ebner 1 sibling, 1 reply; 13+ messages in thread From: SeongJae Park @ 2026-04-30 1:03 UTC (permalink / raw) To: Manuel Ebner Cc: SeongJae Park, Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel, workflows, linux-mm, Geert Uytterhoeven On Wed, 29 Apr 2026 09:27:04 +0200 Manuel Ebner <manuelebner@mailbox.org> wrote: > put the optional argument (gfp) in square brackets > add default value = GFP_KERNEL > > eg. ptr = kmalloc_obj(*ptr, gfp); > -> ptr = kmalloc_obj(*ptr [, gfp] ); > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> I have a trivial question below, but because it is trivial, Acked-by: SeongJae Park <sj@kernel.org> > --- > Documentation/process/deprecated.rst | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst > index fed56864d036..ac75b7ecac47 100644 > --- a/Documentation/process/deprecated.rst > +++ b/Documentation/process/deprecated.rst > @@ -392,13 +392,14 @@ allocations. For example, these open coded assignments:: > > 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); > - __auto_type ptr = kmalloc_obj(struct foo, 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] ); > + __auto_type ptr = kmalloc_obj(struct foo [, gfp] ); > + > +The argument gfp is optional, the default value is GFP_KERNEL. > 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 Like 'ptr->flex_member' and 'count', why don't you enclose 'gfp' and 'GFP_KERNEL' with backticks ('`')? Thanks, SJ [...] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional 2026-04-30 1:03 ` SeongJae Park @ 2026-05-01 9:19 ` Manuel Ebner 0 siblings, 0 replies; 13+ messages in thread From: Manuel Ebner @ 2026-05-01 9:19 UTC (permalink / raw) To: SeongJae Park Cc: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook, linux-kernel, workflows, linux-mm, Geert Uytterhoeven On Wed, 2026-04-29 at 18:03 -0700, SeongJae Park wrote: > On Wed, 29 Apr 2026 09:27:04 +0200 Manuel Ebner <manuelebner@mailbox.org> > wrote: > > > put the optional argument (gfp) in square brackets > > add default value = GFP_KERNEL > > > > eg. ptr = kmalloc_obj(*ptr, gfp); > > -> ptr = kmalloc_obj(*ptr [, gfp] ); > > > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> > > I have a trivial question below, but because it is trivial, > > Acked-by: SeongJae Park <sj@kernel.org> > > > --- > > Documentation/process/deprecated.rst | 15 ++++++++------- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/process/deprecated.rst > > b/Documentation/process/deprecated.rst > > index fed56864d036..ac75b7ecac47 100644 > > --- a/Documentation/process/deprecated.rst > > +++ b/Documentation/process/deprecated.rst > > @@ -392,13 +392,14 @@ allocations. For example, these open coded > > assignments:: > > > > 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); > > - __auto_type ptr = kmalloc_obj(struct foo, 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] ); > > + __auto_type ptr = kmalloc_obj(struct foo [, gfp] ); > > + > > +The argument gfp is optional, the default value is GFP_KERNEL. > > 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 > > Like 'ptr->flex_member' and 'count', why don't you enclose 'gfp' and > 'GFP_KERNEL' with backticks ('`')? I didn't know what ` is doing, so didn't consider it. It makes sense to enclose these two. should __counted_by() be enclosed aswell? > Thanks, > SJ Thanks Manuel --- The possibility of getting blamed has to be earned. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-04-29 7:08 [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Manuel Ebner 2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner 2026-04-29 7:27 ` [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional Manuel Ebner @ 2026-05-03 14:56 ` Jonathan Corbet 2026-05-03 15:47 ` Manuel Ebner 2 siblings, 1 reply; 13+ messages in thread From: Jonathan Corbet @ 2026-05-03 14:56 UTC (permalink / raw) To: Manuel Ebner, Shuah Khan, linux-doc, Kees Cook Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm, Manuel Ebner Manuel Ebner <manuelebner@mailbox.org> writes: > Update the documentation to reflect new type-aware kmalloc-family as > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > and family") OK, I have applied this series. While doing so, I restored the "gfp" parameter in the changelog portion where it had been mistakenly removed. Thanks, jon ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-05-03 14:56 ` [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Jonathan Corbet @ 2026-05-03 15:47 ` Manuel Ebner 2026-05-03 15:51 ` Jonathan Corbet 0 siblings, 1 reply; 13+ messages in thread From: Manuel Ebner @ 2026-05-03 15:47 UTC (permalink / raw) To: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm On Sun, 2026-05-03 at 08:56 -0600, Jonathan Corbet wrote: > Manuel Ebner <manuelebner@mailbox.org> writes: > > > Update the documentation to reflect new type-aware kmalloc-family as > > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() > > and family") > > OK, I have applied this series. While doing so, I restored the "gfp" > parameter in the changelog portion where it had been mistakenly removed. That's good, thanks. I had two more changes lined up for v5 of this series: - ptr = kmalloc(sizeof(struct foo, gfp); + ptr = kmalloc(sizeof(struct foo), gfp); and -The argument gfp is optional, the default value is GFP_KERNEL. +The argument `gfp` is optional, the default value is `GFP_KERNEL`. I don't know how to go forward with this. please advice Thanks Manuel > Thanks, > > jon ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family 2026-05-03 15:47 ` Manuel Ebner @ 2026-05-03 15:51 ` Jonathan Corbet 0 siblings, 0 replies; 13+ messages in thread From: Jonathan Corbet @ 2026-05-03 15:51 UTC (permalink / raw) To: Manuel Ebner, Shuah Khan, linux-doc, Kees Cook Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm Manuel Ebner <manuelebner@mailbox.org> writes: > On Sun, 2026-05-03 at 08:56 -0600, Jonathan Corbet wrote: >> Manuel Ebner <manuelebner@mailbox.org> writes: >> >> > Update the documentation to reflect new type-aware kmalloc-family as >> > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() >> > and family") >> >> OK, I have applied this series. While doing so, I restored the "gfp" >> parameter in the changelog portion where it had been mistakenly removed. > > That's good, thanks. > I had two more changes lined up for v5 of this series: > > - ptr = kmalloc(sizeof(struct foo, gfp); > + ptr = kmalloc(sizeof(struct foo), gfp); > > and > > -The argument gfp is optional, the default value is GFP_KERNEL. > +The argument `gfp` is optional, the default value is `GFP_KERNEL`. > > I don't know how to go forward with this. > please advice Make a new patch on top of docs-next with the additional changes you want to do. Thanks, jon ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2026-05-03 15:51 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-04-29 7:08 [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Manuel Ebner 2026-04-29 7:14 ` [PATCH v4 1/3] " Manuel Ebner 2026-04-29 8:00 ` Vlastimil Babka 2026-04-30 0:53 ` SeongJae Park 2026-04-30 1:00 ` SeongJae Park 2026-05-01 9:12 ` Manuel Ebner 2026-04-29 7:27 ` [PATCH v4 3/3] Documentation: deprecated.rst: kmalloc-family: mark argument as optional Manuel Ebner 2026-04-29 8:01 ` Vlastimil Babka 2026-04-30 1:03 ` SeongJae Park 2026-05-01 9:19 ` Manuel Ebner 2026-05-03 14:56 ` [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family Jonathan Corbet 2026-05-03 15:47 ` Manuel Ebner 2026-05-03 15:51 ` Jonathan Corbet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox