* [TEST] send-email check
From: Wis Chiang @ 2026-05-01 6:17 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548
Hi,
This is a test email to kernelnewbies.
Thanks,
Wis Chiang
^ permalink raw reply
* [PATCH v2 3/3] Documentation: deprecated.rst: type-aware kmalloc-family: mark optional argument as such
From: Manuel Ebner @ 2026-04-20 16:50 UTC (permalink / raw)
Cc: manuelebner, kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <20260420164234.217133-2-manuelebner@mailbox.org>
put the optional argument (gfp) in square brackets
eg. ptr = kmalloc_obj(*ptr, gfp);
-> ptr = kmalloc_obj(*ptr, [gfp]);
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/deprecated.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..b431993fd08e 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -392,12 +392,12 @@ 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]);
If `ptr->flex_member` is annotated with __counted_by(), the allocation
will automatically fail if `count` is larger than the maximum
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: RCU: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-20 16:48 UTC (permalink / raw)
Cc: manuelebner, kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <20260420164234.217133-2-manuelebner@mailbox.org>
Update Documentation/RCU/* 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);
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/RCU/Design/Requirements/Requirements.rst | 6 +++---
Documentation/RCU/listRCU.rst | 2 +-
Documentation/RCU/whatisRCU.rst | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index b5cdbba3ec2e..faca5a9c8c12 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``->b`` fields.
1 bool add_gp_buggy(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -228,7 +228,7 @@ their rights to reorder this code as follows:
1 bool add_gp_buggy_optimized(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -264,7 +264,7 @@ shows an example of insertion:
1 bool add_gp(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
diff --git a/Documentation/RCU/listRCU.rst b/Documentation/RCU/listRCU.rst
index d8bb98623c12..48c7272a4ccc 100644
--- a/Documentation/RCU/listRCU.rst
+++ b/Documentation/RCU/listRCU.rst
@@ -276,7 +276,7 @@ The RCU version of audit_upd_rule() is as follows::
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
- ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ ne = kmalloc_obj(*entry, GFP_ATOMIC);
if (ne == NULL)
return -ENOMEM;
audit_copy_rule(&ne->rule, &e->rule);
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index a1582bd653d1..770aab8ea36a 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -468,7 +468,7 @@ uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+ new_fp = kmalloc_obj(*new_fp);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
@@ -570,7 +570,7 @@ The foo_update_a() function might then be written as follows::
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+ new_fp = kmalloc_obj(*new_fp);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
--
2.53.0
^ permalink raw reply related
* [PATCH] [PATCH v2 1/3] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-20 16:45 UTC (permalink / raw)
Cc: manuelebner, kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <20260420164234.217133-2-manuelebner@mailbox.org>
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/core-api/memory-allocation.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/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst
index 0f19dd524323..8379775f17d3 100644
--- a/Documentation/core-api/memory-allocation.rst
+++ b/Documentation/core-api/memory-allocation.rst
@@ -135,7 +135,7 @@ Selecting memory allocator
The most straightforward way to allocate memory is to use a function
from the kmalloc() family. And, to be on the safe side it's best to use
routines that set memory to zero, like kzalloc(). If you need to
-allocate memory for an array, there are kmalloc_array() and kcalloc()
+allocate memory for an array, there are kmalloc_objs() and kzalloc_objs()
helpers. The helpers struct_size(), array_size() and array3_size() can
be used to safely calculate object sizes without overflowing.
@@ -151,7 +151,7 @@ sizes, the alignment is guaranteed to be at least the largest power-of-two
divisor of the size.
Chunks allocated with kmalloc() can be resized with krealloc(). Similarly
-to kmalloc_array(): a helper for resizing arrays is provided in the form of
+to kmalloc_objs(): a helper for resizing arrays is provided in the form of
krealloc_array().
For large allocations you can use vmalloc() and vzalloc(), or directly
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
* [PATCH v2 0/3] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-20 16:42 UTC (permalink / raw)
To: kernel-janitors, linux-kernel-mentees, linux-newbie; +Cc: 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);
I have also thought about adding a few cases to checkpatch.pl, but this
will take me more time, and i want to get this series finished.
[v1] -> [v2]:
put RCU/* in a seperate patch [Patch 2/3]
Remove 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
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Dan Carpenter @ 2026-04-18 11:44 UTC (permalink / raw)
To: Manuel Ebner; +Cc: kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <980be93ce680c831c37dbeeb070135b2fc8f4fb8.camel@mailbox.org>
On Sat, Apr 18, 2026 at 12:45:19PM +0200, Manuel Ebner wrote:
> On Sat, 2026-04-18 at 13:27 +0300, Dan Carpenter wrote:
> > On Sat, Apr 18, 2026 at 11:30:48AM +0200, Manuel Ebner wrote:
> > > Would a patch like this one make sense?
> > > I think i need help with the change log. Is there something to much or missing?
> > >
> > > ptr = kmalloc(sizeof(*ptr), gfp);
> > > -> ptr = kmalloc_obj(*ptr, gfp);
> > >
> > > This one is done. The ones below are not done yet.
> > >
> > > ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> > > -> ptr = kmalloc_obj(*ptr, gfp);
> > > ptr = kzalloc(sizeof(*ptr), gfp);
> > > > ptr = kzalloc_obj(*ptr, gfp);
> > > ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> > > -> ptr = kmalloc_objs(*ptr, count, gfp);
> > > ptr = kcalloc(count, sizeof(*ptr), gfp);
> > > -> ptr = kzalloc_objs(*ptr, count, gfp);
> > >
> > > change log:
> > > [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
> > >
> > > 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, gfp);
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> >
> > Yeah. Fix up the commit message and that could probably be merged
> > through the documentation tree.
>
> how do i fix the commit message?
> what's even the issue?
I just meant that you should remove the stuff like "Would a patch like
this one make sense?"...
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-18 10:45 UTC (permalink / raw)
To: Dan Carpenter; +Cc: kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <aeNcgSu8kVEyWbzY@stanley.mountain>
On Sat, 2026-04-18 at 13:27 +0300, Dan Carpenter wrote:
> On Sat, Apr 18, 2026 at 11:30:48AM +0200, Manuel Ebner wrote:
> > Would a patch like this one make sense?
> > I think i need help with the change log. Is there something to much or missing?
> >
> > ptr = kmalloc(sizeof(*ptr), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> >
> > This one is done. The ones below are not done yet.
> >
> > ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> > ptr = kzalloc(sizeof(*ptr), gfp);
> > > ptr = kzalloc_obj(*ptr, gfp);
> > ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> > -> ptr = kmalloc_objs(*ptr, count, gfp);
> > ptr = kcalloc(count, sizeof(*ptr), gfp);
> > -> ptr = kzalloc_objs(*ptr, count, gfp);
> >
> > change log:
> > [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
> >
> > 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, gfp);
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
>
> Yeah. Fix up the commit message and that could probably be merged
> through the documentation tree.
how do i fix the commit message?
what's even the issue?
is the one-line-message ok?
> Probably no need to split it up
> by subsystem, but you should CC the affected subsystems.
Thanks, i struggled with who to send it to.
> regards,
> dan carpener
can i add
Reviewed-by: Dan Carpenter <error27@gmail.com>
?
Thanks,
Manuel
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Dan Carpenter @ 2026-04-18 10:27 UTC (permalink / raw)
To: Manuel Ebner; +Cc: kernel-janitors, linux-kernel-mentees, linux-newbie
In-Reply-To: <20260418093101.130335-6-manuelebner@mailbox.org>
On Sat, Apr 18, 2026 at 11:30:48AM +0200, Manuel Ebner wrote:
> Would a patch like this one make sense?
> I think i need help with the change log. Is there something to much or missing?
>
> ptr = kmalloc(sizeof(*ptr), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
>
> This one is done. The ones below are not done yet.
>
> ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
> ptr = kzalloc(sizeof(*ptr), gfp);
> > ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> -> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> -> ptr = kzalloc_objs(*ptr, count, gfp);
>
> change log:
> [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
>
> 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, gfp);
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Yeah. Fix up the commit message and that could probably be merged
through the documentation tree. Probably no need to split it up
by subsystem, but you should CC the affected subsystems.
regards,
dan carpener
^ permalink raw reply
* [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-18 9:30 UTC (permalink / raw)
To: kernel-janitors, linux-kernel-mentees, linux-newbie; +Cc: Manuel Ebner
Would a patch like this one make sense?
I think i need help with the change log. Is there something to much or missing?
ptr = kmalloc(sizeof(*ptr), gfp);
-> ptr = kmalloc_obj(*ptr, gfp);
This one is done. The ones below are not done yet.
ptr = kmalloc(sizeof(struct some_obj_name), gfp);
-> ptr = kmalloc_obj(*ptr, gfp);
ptr = kzalloc(sizeof(*ptr), gfp);
> ptr = kzalloc_obj(*ptr, gfp);
ptr = kmalloc_array(count, sizeof(*ptr), gfp);
-> ptr = kmalloc_objs(*ptr, count, gfp);
ptr = kcalloc(count, sizeof(*ptr), gfp);
-> ptr = kzalloc_objs(*ptr, count, gfp);
change log:
[PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
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, gfp);
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/RCU/Design/Requirements/Requirements.rst | 6 +++---
Documentation/RCU/listRCU.rst | 2 +-
Documentation/RCU/whatisRCU.rst | 4 ++--
Documentation/core-api/kref.rst | 4 ++--
Documentation/core-api/list.rst | 4 ++--
Documentation/kernel-hacking/locking.rst | 4 ++--
Documentation/locking/locktypes.rst | 4 ++--
Documentation/process/coding-style.rst | 2 +-
Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 4 ++--
Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 ++--
Documentation/translations/it_IT/locking/locktypes.rst | 4 ++--
Documentation/translations/it_IT/process/coding-style.rst | 2 +-
Documentation/translations/sp_SP/process/coding-style.rst | 2 +-
Documentation/translations/zh_CN/core-api/kref.rst | 4 ++--
Documentation/translations/zh_CN/process/coding-style.rst | 2 +-
Documentation/translations/zh_TW/process/coding-style.rst | 2 +-
16 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
index b5cdbba3ec2e..faca5a9c8c12 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``->b`` fields.
1 bool add_gp_buggy(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p, GFP_KERNEL);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -228,7 +228,7 @@ their rights to reorder this code as follows:
1 bool add_gp_buggy_optimized(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p, GFP_KERNEL);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -264,7 +264,7 @@ shows an example of insertion:
1 bool add_gp(int a, int b)
2 {
- 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
+ 3 p = kmalloc_obj(*p, GFP_KERNEL);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
diff --git a/Documentation/RCU/listRCU.rst b/Documentation/RCU/listRCU.rst
index d8bb98623c12..48c7272a4ccc 100644
--- a/Documentation/RCU/listRCU.rst
+++ b/Documentation/RCU/listRCU.rst
@@ -276,7 +276,7 @@ The RCU version of audit_upd_rule() is as follows::
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
- ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ ne = kmalloc_obj(*entry, GFP_ATOMIC);
if (ne == NULL)
return -ENOMEM;
audit_copy_rule(&ne->rule, &e->rule);
diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst
index a1582bd653d1..770aab8ea36a 100644
--- a/Documentation/RCU/whatisRCU.rst
+++ b/Documentation/RCU/whatisRCU.rst
@@ -468,7 +468,7 @@ uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+ new_fp = kmalloc_obj(*new_fp, GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
@@ -570,7 +570,7 @@ The foo_update_a() function might then be written as follows::
struct foo *new_fp;
struct foo *old_fp;
- new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
+ new_fp = kmalloc_obj(*new_fp, GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
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, GFP_KERNEL);
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, GFP_KERNEL);
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, GFP_KERNEL);
if (!grock)
return -ENOMEM;
grock->name = "Grock";
@@ -123,7 +123,7 @@ list:
/* State 2 */
- dimitri = kzalloc(sizeof(*dimitri), GFP_KERNEL);
+ dimitri = kzalloc_obj(*dimitri, GFP_KERNEL);
if (!dimitri)
return -ENOMEM;
dimitri->name = "Dimitri";
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, GFP_KERNEL)) == 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, GFP_KERNEL)) == 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..6bf71ea67744 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -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
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 895752cbcedd..b79e3ed16dc5 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -1737,7 +1737,7 @@ callback::
{
struct my_pcm_data *data;
....
- data = kmalloc(sizeof(*data), GFP_KERNEL);
+ data = kmalloc_obj(*data, GFP_KERNEL);
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, GFP_KERNEL);
hw->private_data = p;
hw->private_free = mydata_free;
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, GFP_KERNEL)) == 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, GFP_KERNEL)) == 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, GFP_KERNEL);
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, GFP_KERNEL);
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_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
* [PATCH] [TESTING] just trying I'm just trying if mailing to a list works now.
From: CarolineChang @ 2026-04-14 6:57 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1584, CarolineChang
Signed-off-by: CarolineChang <caroline.chang.0.0@gmail.com>
---
test.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 test.txt
diff --git a/test.txt b/test.txt
new file mode 100644
index 0000000..9daeafb
--- /dev/null
+++ b/test.txt
@@ -0,0 +1 @@
+test
--
2.43.0
^ permalink raw reply related
* [TEST v2 1/1] [WIP] Try compile linux on macOS with the help of nix
From: jw910731 @ 2026-04-12 13:13 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, jw910731
In-Reply-To: <cover.1775999068.git.jw910731@gmail.com>
From: jw910731 <jw910731@gmail.com>
Signed-off-by: Wen-Yuan Wu <jw910731@gmail.com>
---
flake.lock | 82 ++++++++++++++++++++++++++++++++
flake.nix | 43 +++++++++++++++++
scripts/Kconfig.include | 2 +-
scripts/install.sh | 2 +-
scripts/macos-include/byteswap.h | 4 ++
scripts/macos-include/elf.h | 24 ++++++++++
scripts/macos-include/endian.h | 8 ++++
scripts/mod/file2alias.c | 3 ++
usr/gen_init_cpio.c | 4 +-
9 files changed, 168 insertions(+), 4 deletions(-)
create mode 100644 flake.lock
create mode 100644 flake.nix
create mode 100644 scripts/macos-include/byteswap.h
create mode 100644 scripts/macos-include/elf.h
create mode 100644 scripts/macos-include/endian.h
diff --git a/flake.lock b/flake.lock
new file mode 100644
index 000000000..e6c1f5f67
--- /dev/null
+++ b/flake.lock
@@ -0,0 +1,82 @@
+{
+ "nodes": {
+ "nixpkgs": {
+ "locked": {
+ "lastModified": 1772963539,
+ "narHash": "sha256-9jVDGZnvCckTGdYT53d/EfznygLskyLQXYwJLKMPsZs=",
+ "owner": "NixOS",
+ "repo": "nixpkgs",
+ "rev": "9dcb002ca1690658be4a04645215baea8b95f31d",
+ "type": "github"
+ },
+ "original": {
+ "owner": "NixOS",
+ "ref": "nixos-unstable",
+ "repo": "nixpkgs",
+ "type": "github"
+ }
+ },
+ "root": {
+ "inputs": {
+ "nixpkgs": "nixpkgs",
+ "rust-overlay": "rust-overlay",
+ "utils": "utils"
+ }
+ },
+ "rust-overlay": {
+ "inputs": {
+ "nixpkgs": [
+ "nixpkgs"
+ ]
+ },
+ "locked": {
+ "lastModified": 1773115373,
+ "narHash": "sha256-bfK9FJFcQth6f3ydYggS5m0z2NRGF/PY6Y2XgZDJ6pg=",
+ "owner": "oxalica",
+ "repo": "rust-overlay",
+ "rev": "1924b4672a2b8e4aee6e6652ec2e59a8d3c5648e",
+ "type": "github"
+ },
+ "original": {
+ "owner": "oxalica",
+ "repo": "rust-overlay",
+ "type": "github"
+ }
+ },
+ "systems": {
+ "locked": {
+ "lastModified": 1681028828,
+ "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
+ "owner": "nix-systems",
+ "repo": "default",
+ "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
+ "type": "github"
+ },
+ "original": {
+ "owner": "nix-systems",
+ "repo": "default",
+ "type": "github"
+ }
+ },
+ "utils": {
+ "inputs": {
+ "systems": "systems"
+ },
+ "locked": {
+ "lastModified": 1731533236,
+ "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
+ "owner": "numtide",
+ "repo": "flake-utils",
+ "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
+ "type": "github"
+ },
+ "original": {
+ "owner": "numtide",
+ "repo": "flake-utils",
+ "type": "github"
+ }
+ }
+ },
+ "root": "root",
+ "version": 7
+}
diff --git a/flake.nix b/flake.nix
new file mode 100644
index 000000000..b2199f6eb
--- /dev/null
+++ b/flake.nix
@@ -0,0 +1,43 @@
+{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ utils.url = "github:numtide/flake-utils";
+ rust-overlay = {
+ url = "github:oxalica/rust-overlay";
+ inputs = {
+ nixpkgs.follows = "nixpkgs";
+ };
+ };
+ };
+ outputs = { self, nixpkgs, utils, rust-overlay }: utils.lib.eachDefaultSystem (system:
+ let
+ overlays = [ (import rust-overlay) ];
+ pkgs = import nixpkgs {
+ inherit system overlays;
+ };
+ pkgsCross = pkgs.pkgsCross.aarch64-multiplatform;
+ in
+ {
+ devShell = pkgsCross.mkShell {
+ nativeBuildInputs = with pkgsCross; [
+ gnumake
+ ncurses
+ flex
+ bison
+ lld
+ rustc
+ rust-bindgen
+ rustfmt
+ clippy
+ pahole
+ ];
+ buildInputs = [];
+ HOSTCC="${pkgs.lib.getBin pkgs.clang}/bin/clang";
+ HOSTLD="${pkgs.lib.getBin pkgs.lld}/bin/lld";
+ HOSTCFLAGS="-I${pkgs.lib.getLib pkgs.libelf}/include -Iscripts/macos-include";
+ NIX_CFLAGS_COMPILE="-march=armv8-a+crypto";
+ RUST_LIB_SRC = "${pkgsCross.rust.packages.stable.rustPlatform.rustLibSrc}";
+ };
+ }
+ );
+}
\ No newline at end of file
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e..c3f38006c 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -54,7 +54,7 @@ as-version := $(shell,set -- $(as-info) && echo $2)
# Get the linker name, version, and error out if it is not supported.
ld-info := $(shell,$(srctree)/scripts/ld-version.sh $(LD))
-$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not supported.)
+$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker $(LD) is not supported.)
ld-name := $(shell,set -- $(ld-info) && echo $1)
ld-version := $(shell,set -- $(ld-info) && echo $2)
diff --git a/scripts/install.sh b/scripts/install.sh
index 05d62ac51..b99183bb8 100755
--- a/scripts/install.sh
+++ b/scripts/install.sh
@@ -6,7 +6,7 @@
# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
# Common code factored out by Masahiro Yamada
-set -e
+set -xe
# Make sure the files actually exist
for file in "${KBUILD_IMAGE}" System.map
diff --git a/scripts/macos-include/byteswap.h b/scripts/macos-include/byteswap.h
new file mode 100644
index 000000000..fd97ed5e1
--- /dev/null
+++ b/scripts/macos-include/byteswap.h
@@ -0,0 +1,4 @@
+#pragma once
+#define bswap_16 __builtin_bswap16
+#define bswap_32 __builtin_bswap32
+#define bswap_64 __builtin_bswap64
diff --git a/scripts/macos-include/elf.h b/scripts/macos-include/elf.h
new file mode 100644
index 000000000..5d42ed858
--- /dev/null
+++ b/scripts/macos-include/elf.h
@@ -0,0 +1,24 @@
+#pragma once
+#include <libelf/gelf.h>
+
+#define STT_SPARC_REGISTER 3
+#define R_386_32 1
+#define R_386_PC32 2
+#define R_MIPS_HI16 5
+#define R_MIPS_LO16 6
+#define R_MIPS_26 4
+#define R_MIPS_32 2
+#define R_ARM_ABS32 2
+#define R_ARM_REL32 3
+#define R_ARM_PC24 1
+#define R_ARM_CALL 28
+#define R_ARM_JUMP24 29
+#define R_ARM_THM_JUMP24 30
+#define R_ARM_THM_PC22 10
+#define R_ARM_MOVW_ABS_NC 43
+#define R_ARM_MOVT_ABS 44
+#define R_ARM_THM_MOVW_ABS_NC 47
+#define R_ARM_THM_MOVT_ABS 48
+#define R_ARM_THM_JUMP19 51
+#define R_AARCH64_ABS64 257
+#define R_AARCH64_PREL64 260
diff --git a/scripts/macos-include/endian.h b/scripts/macos-include/endian.h
new file mode 100644
index 000000000..6a27c4a0b
--- /dev/null
+++ b/scripts/macos-include/endian.h
@@ -0,0 +1,8 @@
+#pragma once
+#include <machine/endian.h>
+#include <libkern/OSByteOrder.h>
+
+#define le16toh(x) OSSwapLittleToHostInt16(x)
+#define le32toh(x) OSSwapLittleToHostInt32(x)
+#define le64toh(x) OSSwapLittleToHostInt64(x)
+#define EM_AARCH64 183
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 4e99393a3..98aee9a4d 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -16,7 +16,10 @@
#include "list.h"
#include "xalloc.h"
+#define _UUID_T
+#define uuid_t int
#include "modpost.h"
+#undef uuid_t
#include "devicetable-offsets.h"
/* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
index b7296edc6..809602912 100644
--- a/usr/gen_init_cpio.c
+++ b/usr/gen_init_cpio.c
@@ -457,7 +457,7 @@ static int cpio_mkfile(const char *name, const char *location,
goto error;
if (size) {
- this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
+ // this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
if (this_read > 0) {
if (this_read > size)
goto error;
@@ -674,7 +674,7 @@ int main (int argc, char *argv[])
break;
case 'o':
outfd = open(optarg,
- O_WRONLY | O_CREAT | O_LARGEFILE | O_TRUNC,
+ O_WRONLY | O_CREAT | O_TRUNC,
0600);
if (outfd < 0) {
fprintf(stderr, "failed to open %s\n", optarg);
--
2.51.2
^ permalink raw reply related
* [PATCH v2] [TEST 0/1] Test with random patches
From: jw910731 @ 2026-04-12 13:13 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, Wen-Yuan Wu
From: Wen-Yuan Wu <jw910731@gmail.com>
Thank's for Nick's feed back, the Signed-off-by field should be fixed to
comply DCO now.
The commit message stays unclear since the revision is mainly for testing.
jw910731 (1):
[WIP] Try compile linux on macOS with the help of nix
flake.lock | 82 ++++++++++++++++++++++++++++++++
flake.nix | 43 +++++++++++++++++
scripts/Kconfig.include | 2 +-
scripts/install.sh | 2 +-
scripts/macos-include/byteswap.h | 4 ++
scripts/macos-include/elf.h | 24 ++++++++++
scripts/macos-include/endian.h | 8 ++++
scripts/mod/file2alias.c | 3 ++
usr/gen_init_cpio.c | 4 +-
9 files changed, 168 insertions(+), 4 deletions(-)
create mode 100644 flake.lock
create mode 100644 flake.nix
create mode 100644 scripts/macos-include/byteswap.h
create mode 100644 scripts/macos-include/elf.h
create mode 100644 scripts/macos-include/endian.h
--
2.51.2
^ permalink raw reply
* Re: [PATCH] [TEST 1/1] [WIP] Try compile linux on macOS with the help of nix
From: Nick Huang @ 2026-04-12 11:26 UTC (permalink / raw)
To: jw910731; +Cc: linux-newbie
In-Reply-To: <aa6e50c518a1873551235553c49db0428e336314.1775973405.git.jw910731@gmail.com>
<jw910731@gmail.com> 於 2026年4月12日週日 下午2:13寫道：
>
> From: jw910731 <jw910731@gmail.com>
>
> Signed-off-by: jw910731 <jw910731@gmail.com>
Hi jw910731
The alias "jw910731" cannot be used for the Signed-off-by line because
it violates the Developer's Certificate of Origin (DCO).
According to the DCO, contributions must not be anonymous; the signer
must use their legal name to establish a clear chain of responsibility
and verify their right to submit the code under an open-source license.
--
Regards,
Nick Huang
> ---
> flake.lock | 82 ++++++++++++++++++++++++++++++++
> flake.nix | 43 +++++++++++++++++
> scripts/Kconfig.include | 2 +-
> scripts/install.sh | 2 +-
> scripts/macos-include/byteswap.h | 4 ++
> scripts/macos-include/elf.h | 24 ++++++++++
> scripts/macos-include/endian.h | 8 ++++
> scripts/mod/file2alias.c | 3 ++
> usr/gen_init_cpio.c | 4 +-
> 9 files changed, 168 insertions(+), 4 deletions(-)
> create mode 100644 flake.lock
> create mode 100644 flake.nix
> create mode 100644 scripts/macos-include/byteswap.h
> create mode 100644 scripts/macos-include/elf.h
> create mode 100644 scripts/macos-include/endian.h
>
> diff --git a/flake.lock b/flake.lock
> new file mode 100644
> index 000000000..e6c1f5f67
> --- /dev/null
> +++ b/flake.lock
> @@ -0,0 +1,82 @@
> +{
> + "nodes": {
> + "nixpkgs": {
> + "locked": {
> + "lastModified": 1772963539,
> + "narHash": "sha256-9jVDGZnvCckTGdYT53d/EfznygLskyLQXYwJLKMPsZs=",
> + "owner": "NixOS",
> + "repo": "nixpkgs",
> + "rev": "9dcb002ca1690658be4a04645215baea8b95f31d",
> + "type": "github"
> + },
> + "original": {
> + "owner": "NixOS",
> + "ref": "nixos-unstable",
> + "repo": "nixpkgs",
> + "type": "github"
> + }
> + },
> + "root": {
> + "inputs": {
> + "nixpkgs": "nixpkgs",
> + "rust-overlay": "rust-overlay",
> + "utils": "utils"
> + }
> + },
> + "rust-overlay": {
> + "inputs": {
> + "nixpkgs": [
> + "nixpkgs"
> + ]
> + },
> + "locked": {
> + "lastModified": 1773115373,
> + "narHash": "sha256-bfK9FJFcQth6f3ydYggS5m0z2NRGF/PY6Y2XgZDJ6pg=",
> + "owner": "oxalica",
> + "repo": "rust-overlay",
> + "rev": "1924b4672a2b8e4aee6e6652ec2e59a8d3c5648e",
> + "type": "github"
> + },
> + "original": {
> + "owner": "oxalica",
> + "repo": "rust-overlay",
> + "type": "github"
> + }
> + },
> + "systems": {
> + "locked": {
> + "lastModified": 1681028828,
> + "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
> + "owner": "nix-systems",
> + "repo": "default",
> + "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
> + "type": "github"
> + },
> + "original": {
> + "owner": "nix-systems",
> + "repo": "default",
> + "type": "github"
> + }
> + },
> + "utils": {
> + "inputs": {
> + "systems": "systems"
> + },
> + "locked": {
> + "lastModified": 1731533236,
> + "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
> + "owner": "numtide",
> + "repo": "flake-utils",
> + "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
> + "type": "github"
> + },
> + "original": {
> + "owner": "numtide",
> + "repo": "flake-utils",
> + "type": "github"
> + }
> + }
> + },
> + "root": "root",
> + "version": 7
> +}
> diff --git a/flake.nix b/flake.nix
> new file mode 100644
> index 000000000..b2199f6eb
> --- /dev/null
> +++ b/flake.nix
> @@ -0,0 +1,43 @@
> +{
> + inputs = {
> + nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
> + utils.url = "github:numtide/flake-utils";
> + rust-overlay = {
> + url = "github:oxalica/rust-overlay";
> + inputs = {
> + nixpkgs.follows = "nixpkgs";
> + };
> + };
> + };
> + outputs = { self, nixpkgs, utils, rust-overlay }: utils.lib.eachDefaultSystem (system:
> + let
> + overlays = [ (import rust-overlay) ];
> + pkgs = import nixpkgs {
> + inherit system overlays;
> + };
> + pkgsCross = pkgs.pkgsCross.aarch64-multiplatform;
> + in
> + {
> + devShell = pkgsCross.mkShell {
> + nativeBuildInputs = with pkgsCross; [
> + gnumake
> + ncurses
> + flex
> + bison
> + lld
> + rustc
> + rust-bindgen
> + rustfmt
> + clippy
> + pahole
> + ];
> + buildInputs = [];
> + HOSTCC="${pkgs.lib.getBin pkgs.clang}/bin/clang";
> + HOSTLD="${pkgs.lib.getBin pkgs.lld}/bin/lld";
> + HOSTCFLAGS="-I${pkgs.lib.getLib pkgs.libelf}/include -Iscripts/macos-include";
> + NIX_CFLAGS_COMPILE="-march=armv8-a+crypto";
> + RUST_LIB_SRC = "${pkgsCross.rust.packages.stable.rustPlatform.rustLibSrc}";
> + };
> + }
> + );
> +}
> \ No newline at end of file
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> index 33193ca6e..c3f38006c 100644
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -54,7 +54,7 @@ as-version := $(shell,set -- $(as-info) && echo $2)
>
> # Get the linker name, version, and error out if it is not supported.
> ld-info := $(shell,$(srctree)/scripts/ld-version.sh $(LD))
> -$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not supported.)
> +$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker $(LD) is not supported.)
> ld-name := $(shell,set -- $(ld-info) && echo $1)
> ld-version := $(shell,set -- $(ld-info) && echo $2)
>
> diff --git a/scripts/install.sh b/scripts/install.sh
This revision could include a more detailed explanation of why this
change was made.
> index 05d62ac51..b99183bb8 100755
> --- a/scripts/install.sh
> +++ b/scripts/install.sh
> @@ -6,7 +6,7 @@
> # Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> # Common code factored out by Masahiro Yamada
>
> -set -e
> +set -xe
>
> # Make sure the files actually exist
> for file in "${KBUILD_IMAGE}" System.map
> diff --git a/scripts/macos-include/byteswap.h b/scripts/macos-include/byteswap.h
> new file mode 100644
> index 000000000..fd97ed5e1
> --- /dev/null
> +++ b/scripts/macos-include/byteswap.h
> @@ -0,0 +1,4 @@
> +#pragma once
> +#define bswap_16 __builtin_bswap16
> +#define bswap_32 __builtin_bswap32
> +#define bswap_64 __builtin_bswap64
> diff --git a/scripts/macos-include/elf.h b/scripts/macos-include/elf.h
> new file mode 100644
> index 000000000..5d42ed858
> --- /dev/null
> +++ b/scripts/macos-include/elf.h
> @@ -0,0 +1,24 @@
> +#pragma once
> +#include <libelf/gelf.h>
> +
> +#define STT_SPARC_REGISTER 3
> +#define R_386_32 1
> +#define R_386_PC32 2
> +#define R_MIPS_HI16 5
> +#define R_MIPS_LO16 6
> +#define R_MIPS_26 4
> +#define R_MIPS_32 2
> +#define R_ARM_ABS32 2
> +#define R_ARM_REL32 3
> +#define R_ARM_PC24 1
> +#define R_ARM_CALL 28
> +#define R_ARM_JUMP24 29
> +#define R_ARM_THM_JUMP24 30
> +#define R_ARM_THM_PC22 10
> +#define R_ARM_MOVW_ABS_NC 43
> +#define R_ARM_MOVT_ABS 44
> +#define R_ARM_THM_MOVW_ABS_NC 47
> +#define R_ARM_THM_MOVT_ABS 48
> +#define R_ARM_THM_JUMP19 51
> +#define R_AARCH64_ABS64 257
> +#define R_AARCH64_PREL64 260
> diff --git a/scripts/macos-include/endian.h b/scripts/macos-include/endian.h
> new file mode 100644
> index 000000000..6a27c4a0b
> --- /dev/null
> +++ b/scripts/macos-include/endian.h
> @@ -0,0 +1,8 @@
> +#pragma once
> +#include <machine/endian.h>
> +#include <libkern/OSByteOrder.h>
> +
> +#define le16toh(x) OSSwapLittleToHostInt16(x)
> +#define le32toh(x) OSSwapLittleToHostInt32(x)
> +#define le64toh(x) OSSwapLittleToHostInt64(x)
> +#define EM_AARCH64 183
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 4e99393a3..98aee9a4d 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -16,7 +16,10 @@
> #include "list.h"
> #include "xalloc.h"
>
> +#define _UUID_T
> +#define uuid_t int
> #include "modpost.h"
> +#undef uuid_t
> #include "devicetable-offsets.h"
>
> /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
> diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> index b7296edc6..809602912 100644
> --- a/usr/gen_init_cpio.c
> +++ b/usr/gen_init_cpio.c
> @@ -457,7 +457,7 @@ static int cpio_mkfile(const char *name, const char *location,
> goto error;
>
> if (size) {
> - this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
> + // this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
> if (this_read > 0) {
> if (this_read > size)
> goto error;
> @@ -674,7 +674,7 @@ int main (int argc, char *argv[])
> break;
> case 'o':
> outfd = open(optarg,
> - O_WRONLY | O_CREAT | O_LARGEFILE | O_TRUNC,
> + O_WRONLY | O_CREAT | O_TRUNC,
> 0600);
> if (outfd < 0) {
> fprintf(stderr, "failed to open %s\n", optarg);
> --
> 2.51.2
>
^ permalink raw reply
* [PATCH] [TEST 1/1] [WIP] Try compile linux on macOS with the help of nix
From: jw910731 @ 2026-04-12 6:12 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, jw910731
In-Reply-To: <cover.1775973405.git.jw910731@gmail.com>
From: jw910731 <jw910731@gmail.com>
Signed-off-by: jw910731 <jw910731@gmail.com>
---
flake.lock | 82 ++++++++++++++++++++++++++++++++
flake.nix | 43 +++++++++++++++++
scripts/Kconfig.include | 2 +-
scripts/install.sh | 2 +-
scripts/macos-include/byteswap.h | 4 ++
scripts/macos-include/elf.h | 24 ++++++++++
scripts/macos-include/endian.h | 8 ++++
scripts/mod/file2alias.c | 3 ++
usr/gen_init_cpio.c | 4 +-
9 files changed, 168 insertions(+), 4 deletions(-)
create mode 100644 flake.lock
create mode 100644 flake.nix
create mode 100644 scripts/macos-include/byteswap.h
create mode 100644 scripts/macos-include/elf.h
create mode 100644 scripts/macos-include/endian.h
diff --git a/flake.lock b/flake.lock
new file mode 100644
index 000000000..e6c1f5f67
--- /dev/null
+++ b/flake.lock
@@ -0,0 +1,82 @@
+{
+ "nodes": {
+ "nixpkgs": {
+ "locked": {
+ "lastModified": 1772963539,
+ "narHash": "sha256-9jVDGZnvCckTGdYT53d/EfznygLskyLQXYwJLKMPsZs=",
+ "owner": "NixOS",
+ "repo": "nixpkgs",
+ "rev": "9dcb002ca1690658be4a04645215baea8b95f31d",
+ "type": "github"
+ },
+ "original": {
+ "owner": "NixOS",
+ "ref": "nixos-unstable",
+ "repo": "nixpkgs",
+ "type": "github"
+ }
+ },
+ "root": {
+ "inputs": {
+ "nixpkgs": "nixpkgs",
+ "rust-overlay": "rust-overlay",
+ "utils": "utils"
+ }
+ },
+ "rust-overlay": {
+ "inputs": {
+ "nixpkgs": [
+ "nixpkgs"
+ ]
+ },
+ "locked": {
+ "lastModified": 1773115373,
+ "narHash": "sha256-bfK9FJFcQth6f3ydYggS5m0z2NRGF/PY6Y2XgZDJ6pg=",
+ "owner": "oxalica",
+ "repo": "rust-overlay",
+ "rev": "1924b4672a2b8e4aee6e6652ec2e59a8d3c5648e",
+ "type": "github"
+ },
+ "original": {
+ "owner": "oxalica",
+ "repo": "rust-overlay",
+ "type": "github"
+ }
+ },
+ "systems": {
+ "locked": {
+ "lastModified": 1681028828,
+ "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
+ "owner": "nix-systems",
+ "repo": "default",
+ "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
+ "type": "github"
+ },
+ "original": {
+ "owner": "nix-systems",
+ "repo": "default",
+ "type": "github"
+ }
+ },
+ "utils": {
+ "inputs": {
+ "systems": "systems"
+ },
+ "locked": {
+ "lastModified": 1731533236,
+ "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
+ "owner": "numtide",
+ "repo": "flake-utils",
+ "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
+ "type": "github"
+ },
+ "original": {
+ "owner": "numtide",
+ "repo": "flake-utils",
+ "type": "github"
+ }
+ }
+ },
+ "root": "root",
+ "version": 7
+}
diff --git a/flake.nix b/flake.nix
new file mode 100644
index 000000000..b2199f6eb
--- /dev/null
+++ b/flake.nix
@@ -0,0 +1,43 @@
+{
+ inputs = {
+ nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+ utils.url = "github:numtide/flake-utils";
+ rust-overlay = {
+ url = "github:oxalica/rust-overlay";
+ inputs = {
+ nixpkgs.follows = "nixpkgs";
+ };
+ };
+ };
+ outputs = { self, nixpkgs, utils, rust-overlay }: utils.lib.eachDefaultSystem (system:
+ let
+ overlays = [ (import rust-overlay) ];
+ pkgs = import nixpkgs {
+ inherit system overlays;
+ };
+ pkgsCross = pkgs.pkgsCross.aarch64-multiplatform;
+ in
+ {
+ devShell = pkgsCross.mkShell {
+ nativeBuildInputs = with pkgsCross; [
+ gnumake
+ ncurses
+ flex
+ bison
+ lld
+ rustc
+ rust-bindgen
+ rustfmt
+ clippy
+ pahole
+ ];
+ buildInputs = [];
+ HOSTCC="${pkgs.lib.getBin pkgs.clang}/bin/clang";
+ HOSTLD="${pkgs.lib.getBin pkgs.lld}/bin/lld";
+ HOSTCFLAGS="-I${pkgs.lib.getLib pkgs.libelf}/include -Iscripts/macos-include";
+ NIX_CFLAGS_COMPILE="-march=armv8-a+crypto";
+ RUST_LIB_SRC = "${pkgsCross.rust.packages.stable.rustPlatform.rustLibSrc}";
+ };
+ }
+ );
+}
\ No newline at end of file
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e..c3f38006c 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -54,7 +54,7 @@ as-version := $(shell,set -- $(as-info) && echo $2)
# Get the linker name, version, and error out if it is not supported.
ld-info := $(shell,$(srctree)/scripts/ld-version.sh $(LD))
-$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not supported.)
+$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker $(LD) is not supported.)
ld-name := $(shell,set -- $(ld-info) && echo $1)
ld-version := $(shell,set -- $(ld-info) && echo $2)
diff --git a/scripts/install.sh b/scripts/install.sh
index 05d62ac51..b99183bb8 100755
--- a/scripts/install.sh
+++ b/scripts/install.sh
@@ -6,7 +6,7 @@
# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
# Common code factored out by Masahiro Yamada
-set -e
+set -xe
# Make sure the files actually exist
for file in "${KBUILD_IMAGE}" System.map
diff --git a/scripts/macos-include/byteswap.h b/scripts/macos-include/byteswap.h
new file mode 100644
index 000000000..fd97ed5e1
--- /dev/null
+++ b/scripts/macos-include/byteswap.h
@@ -0,0 +1,4 @@
+#pragma once
+#define bswap_16 __builtin_bswap16
+#define bswap_32 __builtin_bswap32
+#define bswap_64 __builtin_bswap64
diff --git a/scripts/macos-include/elf.h b/scripts/macos-include/elf.h
new file mode 100644
index 000000000..5d42ed858
--- /dev/null
+++ b/scripts/macos-include/elf.h
@@ -0,0 +1,24 @@
+#pragma once
+#include <libelf/gelf.h>
+
+#define STT_SPARC_REGISTER 3
+#define R_386_32 1
+#define R_386_PC32 2
+#define R_MIPS_HI16 5
+#define R_MIPS_LO16 6
+#define R_MIPS_26 4
+#define R_MIPS_32 2
+#define R_ARM_ABS32 2
+#define R_ARM_REL32 3
+#define R_ARM_PC24 1
+#define R_ARM_CALL 28
+#define R_ARM_JUMP24 29
+#define R_ARM_THM_JUMP24 30
+#define R_ARM_THM_PC22 10
+#define R_ARM_MOVW_ABS_NC 43
+#define R_ARM_MOVT_ABS 44
+#define R_ARM_THM_MOVW_ABS_NC 47
+#define R_ARM_THM_MOVT_ABS 48
+#define R_ARM_THM_JUMP19 51
+#define R_AARCH64_ABS64 257
+#define R_AARCH64_PREL64 260
diff --git a/scripts/macos-include/endian.h b/scripts/macos-include/endian.h
new file mode 100644
index 000000000..6a27c4a0b
--- /dev/null
+++ b/scripts/macos-include/endian.h
@@ -0,0 +1,8 @@
+#pragma once
+#include <machine/endian.h>
+#include <libkern/OSByteOrder.h>
+
+#define le16toh(x) OSSwapLittleToHostInt16(x)
+#define le32toh(x) OSSwapLittleToHostInt32(x)
+#define le64toh(x) OSSwapLittleToHostInt64(x)
+#define EM_AARCH64 183
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 4e99393a3..98aee9a4d 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -16,7 +16,10 @@
#include "list.h"
#include "xalloc.h"
+#define _UUID_T
+#define uuid_t int
#include "modpost.h"
+#undef uuid_t
#include "devicetable-offsets.h"
/* We use the ELF typedefs for kernel_ulong_t but bite the bullet and
diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
index b7296edc6..809602912 100644
--- a/usr/gen_init_cpio.c
+++ b/usr/gen_init_cpio.c
@@ -457,7 +457,7 @@ static int cpio_mkfile(const char *name, const char *location,
goto error;
if (size) {
- this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
+ // this_read = copy_file_range(file, NULL, outfd, NULL, size, 0);
if (this_read > 0) {
if (this_read > size)
goto error;
@@ -674,7 +674,7 @@ int main (int argc, char *argv[])
break;
case 'o':
outfd = open(optarg,
- O_WRONLY | O_CREAT | O_LARGEFILE | O_TRUNC,
+ O_WRONLY | O_CREAT | O_TRUNC,
0600);
if (outfd < 0) {
fprintf(stderr, "failed to open %s\n", optarg);
--
2.51.2
^ permalink raw reply related
* [PATCH] [TEST 0/1] Test with random patches
From: jw910731 @ 2026-04-12 6:12 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, jw910731
From: jw910731 <jw910731@gmail.com>
Test message with some random untested patch.
jw910731 (1):
[WIP] Try compile linux on macOS with the help of nix
flake.lock | 82 ++++++++++++++++++++++++++++++++
flake.nix | 43 +++++++++++++++++
scripts/Kconfig.include | 2 +-
scripts/install.sh | 2 +-
scripts/macos-include/byteswap.h | 4 ++
scripts/macos-include/elf.h | 24 ++++++++++
scripts/macos-include/endian.h | 8 ++++
scripts/mod/file2alias.c | 3 ++
usr/gen_init_cpio.c | 4 +-
9 files changed, 168 insertions(+), 4 deletions(-)
create mode 100644 flake.lock
create mode 100644 flake.nix
create mode 100644 scripts/macos-include/byteswap.h
create mode 100644 scripts/macos-include/elf.h
create mode 100644 scripts/macos-include/endian.h
--
2.51.2
^ permalink raw reply
* [PATCH] [TESTING] just trying
From: ChengHao Yang @ 2026-04-11 14:46 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, ChengHao Yang
I'm just trying if mailing to a list works now.
Signed-off-by: ChengHao Yang <tico88612@gmail.com>
---
test.txt | 1 +
1 file changed, 1 insertion(+)
create mode 100644 test.txt
diff --git a/test.txt b/test.txt
new file mode 100644
index 0000000..ccc3e7b
--- /dev/null
+++ b/test.txt
@@ -0,0 +1 @@
+aaaaa
--
2.43.0
^ permalink raw reply related
* Re: net: question on Liquidio II link speed management code, i suspect it's a bit incomplete
From: Nick Huang @ 2026-04-01 0:35 UTC (permalink / raw)
To: Florian Heigl; +Cc: linux-newbie
In-Reply-To: <18989BCB-DC88-4CAE-9145-43F853ADB3D9@gmail.com>
Florian Heigl <florian.heigl@gmail.com> 於 2026年3月31日週二 下午5:36寫道：
>
> I’m trying to wrap my head around the link speed setting mechanism for the Cavium LiquidIO II / CN23XX NICs. I have a few of those for playing around and try to make them more accessible for others.
>
> I’m on Alpine Linux edge, running 6.18.19
>
> The card defaults to 25gbit, and when I try to set the link speed from ethtool it doesn’t work.
> "Changing speed is not supported“ in dmesg and in ethtool it’ll say
>
> tschike:/tmp# ethtool -s eth0 speed 10000
> netlink error: link settings update failed
> netlink error: Not supported
>
> that was odd since I can find that that support IS in the kernel.
>
> https://lists.openwall.net/netdev/2018/05/08/21
>
>
>
> Today I was looking at this again, and specifically at how the flag no_speed_setting comes into existence.
> I found that happens in lio.core.c (drivers/net/cavium/liquidio):
>
> specifically here
> var = be32_to_cpu((__force __be32)resp->speed)
> if that sends back a ffff it’ll end up at the default link speed and deny setting it.
>
>
> https://gist.github.com/FlorianHeigl/de72c603b1579dd94dc9ecbeb290a36c?permalink_comment_id=6068358#gistcomment-6068358
>
> I got the strong suspicion that the code for that decision making is incomplete.
> common scenarios:
> - if the card has link at 10g, it’ll send 10g, and you’ll be able to switch link speed via ethtool
> - if the card has link at 25g, it’ll send 25g, and you’ll be able to switch link speed via ethtool
> - if the card has a 10g cable and tries to talk 25g it will not have a link and no idea what to do.
>
> >i think it the driver then ends up with no negotiated speed state,
> and in that situation, with the current implementation you can never set the right speed<
> this would explain the actual behaviour I see, and it would explain it better than just looking for
> differences between the old SDK and fresher in-kernel code.
> the supported link modes in ethtool are also „wrong" (only shows 25g, should show 10g, 25g)
>
>
>
> i’m just not sure how to prove it from the code. I can point at three relevant opcodes in liquidio_common.h
>
>
> #define OPCODE_NIC_UBOOT_CTL 0x17
> #define SEAPI_CMD_SPEED_SET 0x2
> #define SEAPI_CMD_SPEED_GET 0x3
>
> but IDK what really happens when it queries the that resp->speed thing (i’m not a dev, obviously)
>
> I’ll test with a different u-boot version but the kernel side is far above my head.
> some other dumb tests I can imagine are changing it to always select 10g or overriding the ‚ffff‘ return.
> it just feels like piking at things blindly. I’d like to know if that even has a point.
> if someone tells me no that logic flaw you imagine doesn’t exist then I can avoid a lot of frustrating tests.
> I don’t have a 25g DAC or SFP that the card accepts, so I can’t even test by just connecting it to itself.
>
>
>
> tl;dr
> I think driver only allows the card to change the link speed when it’s not really important to be able to
> I think the supported link speeds are reported wrong
> if someone with a bigger brain or more practice could look at the logic and see if my suspicions hold up, or tell me a reasonable next step to take?
>
>
Hi Florian
I recommend sending your inquiry to the relevant subsystem mailing
list as well. In this case, netdev@vger.kernel.org would be the
appropriate place. Since not all maintainers follow linux-newbie,
targeting the specific subsystem is usually more effective. You can
refer to this thread for more details:
https://lore.kernel.org/all/20210927090347.GA2533@linux.asia-northeast3-a.c.our-ratio-313919.internal/
Hope this helps!
--
Regards,
Nick Huang
^ permalink raw reply
* net: question on Liquidio II link speed management code, i suspect it's a bit incomplete
From: Florian Heigl @ 2026-03-31 9:35 UTC (permalink / raw)
To: linux-newbie
I’m trying to wrap my head around the link speed setting mechanism for the Cavium LiquidIO II / CN23XX NICs. I have a few of those for playing around and try to make them more accessible for others.
I’m on Alpine Linux edge, running 6.18.19
The card defaults to 25gbit, and when I try to set the link speed from ethtool it doesn’t work.
"Changing speed is not supported“ in dmesg and in ethtool it’ll say
tschike:/tmp# ethtool -s eth0 speed 10000
netlink error: link settings update failed
netlink error: Not supported
that was odd since I can find that that support IS in the kernel.
https://lists.openwall.net/netdev/2018/05/08/21
Today I was looking at this again, and specifically at how the flag no_speed_setting comes into existence.
I found that happens in lio.core.c (drivers/net/cavium/liquidio):
specifically here
var = be32_to_cpu((__force __be32)resp->speed)
if that sends back a ffff it’ll end up at the default link speed and deny setting it.
https://gist.github.com/FlorianHeigl/de72c603b1579dd94dc9ecbeb290a36c?permalink_comment_id=6068358#gistcomment-6068358
I got the strong suspicion that the code for that decision making is incomplete.
common scenarios:
- if the card has link at 10g, it’ll send 10g, and you’ll be able to switch link speed via ethtool
- if the card has link at 25g, it’ll send 25g, and you’ll be able to switch link speed via ethtool
- if the card has a 10g cable and tries to talk 25g it will not have a link and no idea what to do.
>i think it the driver then ends up with no negotiated speed state,
and in that situation, with the current implementation you can never set the right speed<
this would explain the actual behaviour I see, and it would explain it better than just looking for
differences between the old SDK and fresher in-kernel code.
the supported link modes in ethtool are also „wrong" (only shows 25g, should show 10g, 25g)
i’m just not sure how to prove it from the code. I can point at three relevant opcodes in liquidio_common.h
#define OPCODE_NIC_UBOOT_CTL 0x17
#define SEAPI_CMD_SPEED_SET 0x2
#define SEAPI_CMD_SPEED_GET 0x3
but IDK what really happens when it queries the that resp->speed thing (i’m not a dev, obviously)
I’ll test with a different u-boot version but the kernel side is far above my head.
some other dumb tests I can imagine are changing it to always select 10g or overriding the ‚ffff‘ return.
it just feels like piking at things blindly. I’d like to know if that even has a point.
if someone tells me no that logic flaw you imagine doesn’t exist then I can avoid a lot of frustrating tests.
I don’t have a 25g DAC or SFP that the card accepts, so I can’t even test by just connecting it to itself.
tl;dr
I think driver only allows the card to change the link speed when it’s not really important to be able to
I think the supported link speeds are reported wrong
if someone with a bigger brain or more practice could look at the logic and see if my suspicions hold up, or tell me a reasonable next step to take?
^ permalink raw reply
* [PATCH] [TESTING] just trying
From: Sheng Kun Chang @ 2026-03-30 12:44 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, Sheng Kun Chang
I'm just trying if mailing to a list works now.
Signed-off-by: Sheng Kun Chang <nothingchang@mirrorstack.ai>
---
testfile | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 testfile
diff --git a/testfile b/testfile
new file mode 100644
index 000000000000..e69de29bb2d1
--
2.39.5 (Apple Git-154)
--
================================================= Mirror Stack | Where AI
ends wasted time.
NOTICE: This email and any attachments are
confidential and intended for the designated recipient(s) only. This
content may be legally privileged. If you have received this email in
error, please delete it and all copies, and immediately notify the sender.
=================================================
^ permalink raw reply
* [PATCH] [TESTING] just trying
From: Jeffrey Wang @ 2026-03-21 12:55 UTC (permalink / raw)
To: linux-newbie; +Cc: jw910731, Jeffrey Wang
I'm just trying if mailing to a list works now.
Signed-off-by: Jeffrey Wang <natsucamellia@gmail.com>
---
testfile | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 testfile
diff --git a/testfile b/testfile
new file mode 100644
index 0000000..e69de29
--
2.35.1
^ permalink raw reply
* Re: [TESTING] newbie: just testing
From: BryanChan432 @ 2026-03-15 23:34 UTC (permalink / raw)
To: vvvdwbvvv; +Cc: linux-newbie
In-Reply-To: <20260312140951.63906-1-vvvdwbvvv@gmail.com>
Hi,
I am new to kernel, just trying to replying emails!!
Bryan
^ permalink raw reply
* [TESTING] just trying
From: Eddie Tsai @ 2026-03-12 14:09 UTC (permalink / raw)
To: linux-newbie; +Cc: Eddie Tsai
diff --git a/test b/test
new file mode 100644
index 0000000..e69de29
--
2.39.5 (Apple Git-154)
^ permalink raw reply
* [TESTING] just trying
From: Eddie Tsai @ 2026-03-06 14:30 UTC (permalink / raw)
To: linux-newbie; +Cc: sef1548, Eddie Tsai
diff --git a/test b/test
new file mode 100644
index 0000000..e69de29
--
2.39.5 (Apple Git-154)
^ permalink raw reply
* [TESTING] just trying
From: Manuel @ 2026-03-05 9:49 UTC (permalink / raw)
To: linux-newbie
I'm just trying if mailing to a list works now.
^ permalink raw reply
* [TESTING]
From: Hans Anda @ 2026-03-05 11:21 UTC (permalink / raw)
To: linux-newbie
just testing if this works
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox