[PATCH 0/7] docs: core-api: Fix stale function names and a broken example

[PATCH 0/7] docs: core-api: Fix stale function names and a broken example

[Karl Mehltretter]

A review of Documentation/core-api turned up a handful of places where
the text names a function that does not exist, or an example command
that cannot work as written.  Each one is a plain typo from the day the
text was written rather than an API rename: for every patch the wrong
name was checked against the tree at the time of the Fixes: commit, and
the correct name exists in current mainline.

The changes are independent of each other and only touch prose and
examples, so each can be applied on its own.

Karl Mehltretter (7):
  docs: cpu_hotplug: Fix multi-instance removal calls
  docs: irq-affinity: Restore grep in example
  docs: dma-attributes: Fix dma_alloc_attrs() name
  docs: swiotlb: Fix maximum mapping size helper
  docs: this_cpu_ops: Fix SRCU helper names
  docs: xarray: Fix xas_try_split() name
  docs: debugobjects: Fix debug_object_init() name

 Documentation/core-api/cpu_hotplug.rst | 4 ++--
 Documentation/core-api/irq/irq-affinity.rst | 2 +-
 Documentation/core-api/dma-attributes.rst | 2 +-
 Documentation/core-api/swiotlb.rst | 2 +-
 Documentation/core-api/this_cpu_ops.rst | 6 +++---
 Documentation/core-api/xarray.rst | 2 +-
 Documentation/core-api/debug-objects.rst | 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

base-commit: 26260251022fbc2f248a3d747a9b2b961b18d2d8
-- 
2.53.0

[PATCH 1/7] docs: cpu_hotplug: Fix multi-instance removal calls

[Karl Mehltretter]

The function is named cpuhp_state_remove_instance(), not
cpuhp_remove_instance().

Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 Documentation/core-api/cpu_hotplug.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
index 6de26d1c6a9ad..f8b3f59a3d5f7 100644
--- a/Documentation/core-api/cpu_hotplug.rst
+++ b/Documentation/core-api/cpu_hotplug.rst
@@ -607,9 +607,9 @@ ONLINE section for notifications on online and offline operation::
    if (ret)
         return ret;
    ....
-   cpuhp_remove_instance(state, &inst1->node);
+   cpuhp_state_remove_instance(state, &inst1->node);
    ....
-   cpuhp_remove_instance(state, &inst2->node);
+   cpuhp_state_remove_instance(state, &inst2->node);
    ....
    cpuhp_remove_multi_state(state);
 
-- 
2.53.0

Re: [PATCH 1/7] docs: cpu_hotplug: Fix multi-instance removal calls

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> The function is named cpuhp_state_remove_instance(), not
> cpuhp_remove_instance().
> 
> Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/cpu_hotplug.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
> index 6de26d1c6a9ad..f8b3f59a3d5f7 100644
> --- a/Documentation/core-api/cpu_hotplug.rst
> +++ b/Documentation/core-api/cpu_hotplug.rst
> @@ -607,9 +607,9 @@ ONLINE section for notifications on online and offline operation::
>     if (ret)
>          return ret;
>     ....
> -   cpuhp_remove_instance(state, &inst1->node);
> +   cpuhp_state_remove_instance(state, &inst1->node);
>     ....
> -   cpuhp_remove_instance(state, &inst2->node);
> +   cpuhp_state_remove_instance(state, &inst2->node);
>     ....
>     cpuhp_remove_multi_state(state);
>  

-- 
~Randy

Re: [PATCH 1/7] docs: cpu_hotplug: Fix multi-instance removal calls

[Jonathan Corbet]

Karl Mehltretter <kmehltretter@gmail.com> writes:

> The function is named cpuhp_state_remove_instance(), not
> cpuhp_remove_instance().
>
> Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
>  Documentation/core-api/cpu_hotplug.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

These patches could really benefit from Fixes tags.  For this one, it
should be:

  Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")

Can I trouble you to fix the rest of them as well?

Thanks,

jon

Re: [PATCH 1/7] docs: cpu_hotplug: Fix multi-instance removal calls

[Karl Mehltretter]

On Mon, Aug 24, 2026 at 10:57:21AM +0100, Jonathan Corbet wrote:
> Karl Mehltretter <kmehltretter@gmail.com> writes:
> 
> > The function is named cpuhp_state_remove_instance(), not
> > cpuhp_remove_instance().
> >
> > Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
> > Assisted-by: Codex:gpt-5.6-sol
> > Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> > ---
> >  Documentation/core-api/cpu_hotplug.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> These patches could really benefit from Fixes tags.  For this one, it
> should be:
> 
>   Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
> 
> Can I trouble you to fix the rest of them as well?

Fixes tags are already there, above the Assisted-By tags.

Thanks,
Karl

Re: [PATCH 1/7] docs: cpu_hotplug: Fix multi-instance removal calls

[Jonathan Corbet]

Karl Mehltretter <kmehltretter@gmail.com> writes:

> On Mon, Aug 24, 2026 at 10:57:21AM +0100, Jonathan Corbet wrote:
>> Karl Mehltretter <kmehltretter@gmail.com> writes:
>> 
>> > The function is named cpuhp_state_remove_instance(), not
>> > cpuhp_remove_instance().
>> >
>> > Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
>> > Assisted-by: Codex:gpt-5.6-sol
>> > Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
>> > ---
>> >  Documentation/core-api/cpu_hotplug.rst | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> These patches could really benefit from Fixes tags.  For this one, it
>> should be:
>> 
>>   Fixes: c9871c800f65 ("Documentation: core-api/cpuhotplug: Rewrite the API section")
>> 
>> Can I trouble you to fix the rest of them as well?
>
> Fixes tags are already there, above the Assisted-By tags.

Obviously what really needed fixing was my caffeine level...sorry for
the noise.

jon

[PATCH 2/7] docs: irq-affinity: Restore grep in example

[Karl Mehltretter]

The command is missing grep between the pipe and its pattern.

Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 Documentation/core-api/irq/irq-affinity.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/core-api/irq/irq-affinity.rst b/Documentation/core-api/irq/irq-affinity.rst
index 9cb460cf60b61..671604c7395fe 100644
--- a/Documentation/core-api/irq/irq-affinity.rst
+++ b/Documentation/core-api/irq/irq-affinity.rst
@@ -53,7 +53,7 @@ Now lets restrict that IRQ to CPU(4-7).
 	--- hell ping statistics ---
 	2779 packets transmitted, 2777 packets received, 0% packet loss
 	round-trip min/avg/max = 0.1/0.5/585.4 ms
-	[root@moon 44]# cat /proc/interrupts |  'CPU\|44:'
+	[root@moon 44]# cat /proc/interrupts | grep 'CPU\|44:'
 		CPU0       CPU1       CPU2       CPU3      CPU4       CPU5        CPU6       CPU7
 	44:       1068       1785       1785       1783      1784       1069        1070       1069   IO-APIC-level  eth1
 
-- 
2.53.0

Re: [PATCH 2/7] docs: irq-affinity: Restore grep in example

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> The command is missing grep between the pipe and its pattern.
> 
> Fixes: 18404756765c ("genirq: Expose default irq affinity mask (take 3)")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/irq/irq-affinity.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/irq/irq-affinity.rst b/Documentation/core-api/irq/irq-affinity.rst
> index 9cb460cf60b61..671604c7395fe 100644
> --- a/Documentation/core-api/irq/irq-affinity.rst
> +++ b/Documentation/core-api/irq/irq-affinity.rst
> @@ -53,7 +53,7 @@ Now lets restrict that IRQ to CPU(4-7).
>  	--- hell ping statistics ---
>  	2779 packets transmitted, 2777 packets received, 0% packet loss
>  	round-trip min/avg/max = 0.1/0.5/585.4 ms
> -	[root@moon 44]# cat /proc/interrupts |  'CPU\|44:'
> +	[root@moon 44]# cat /proc/interrupts | grep 'CPU\|44:'
>  		CPU0       CPU1       CPU2       CPU3      CPU4       CPU5        CPU6       CPU7
>  	44:       1068       1785       1785       1783      1784       1069        1070       1069   IO-APIC-level  eth1
>  

-- 
~Randy

[PATCH 3/7] docs: dma-attributes: Fix dma_alloc_attrs() name

[Karl Mehltretter]

dma_alloc_attr() does not exist; the allocation API is
dma_alloc_attrs().

Fixes: d5724f172fd1 ("common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 Documentation/core-api/dma-attributes.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
index 123c8468d58f2..067ce6dbb404b 100644
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -34,7 +34,7 @@ such mapping is non-trivial task and consumes very limited resources
 (like kernel virtual address space or dma consistent address space).
 Buffers allocated with this attribute can be only passed to user space
 by calling dma_mmap_attrs(). By using this API, you are guaranteeing
-that you won't dereference the pointer returned by dma_alloc_attr(). You
+that you won't dereference the pointer returned by dma_alloc_attrs(). You
 can treat it as a cookie that must be passed to dma_mmap_attrs() and
 dma_free_attrs(). Make sure that both of these also get this attribute
 set on each call.
-- 
2.53.0

Re: [PATCH 3/7] docs: dma-attributes: Fix dma_alloc_attrs() name

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> dma_alloc_attr() does not exist; the allocation API is
> dma_alloc_attrs().
> 
> Fixes: d5724f172fd1 ("common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/dma-attributes.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
> index 123c8468d58f2..067ce6dbb404b 100644
> --- a/Documentation/core-api/dma-attributes.rst
> +++ b/Documentation/core-api/dma-attributes.rst
> @@ -34,7 +34,7 @@ such mapping is non-trivial task and consumes very limited resources
>  (like kernel virtual address space or dma consistent address space).
>  Buffers allocated with this attribute can be only passed to user space
>  by calling dma_mmap_attrs(). By using this API, you are guaranteeing
> -that you won't dereference the pointer returned by dma_alloc_attr(). You
> +that you won't dereference the pointer returned by dma_alloc_attrs(). You
>  can treat it as a cookie that must be passed to dma_mmap_attrs() and
>  dma_free_attrs(). Make sure that both of these also get this attribute
>  set on each call.

-- 
~Randy

Re: [PATCH 3/7] docs: dma-attributes: Fix dma_alloc_attrs() name

[Marek Szyprowski]

On 22.08.2026 14:16, Karl Mehltretter wrote:
> dma_alloc_attr() does not exist; the allocation API is
> dma_alloc_attrs().
>
> Fixes: d5724f172fd1 ("common: DMA-mapping: add DMA_ATTR_NO_KERNEL_MAPPING attribute")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  Documentation/core-api/dma-attributes.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
> index 123c8468d58f2..067ce6dbb404b 100644
> --- a/Documentation/core-api/dma-attributes.rst
> +++ b/Documentation/core-api/dma-attributes.rst
> @@ -34,7 +34,7 @@ such mapping is non-trivial task and consumes very limited resources
>  (like kernel virtual address space or dma consistent address space).
>  Buffers allocated with this attribute can be only passed to user space
>  by calling dma_mmap_attrs(). By using this API, you are guaranteeing
> -that you won't dereference the pointer returned by dma_alloc_attr(). You
> +that you won't dereference the pointer returned by dma_alloc_attrs(). You
>  can treat it as a cookie that must be passed to dma_mmap_attrs() and
>  dma_free_attrs(). Make sure that both of these also get this attribute
>  set on each call.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH 4/7] docs: swiotlb: Fix maximum mapping size helper

[Karl Mehltretter]

The DMA helper is named dma_max_mapping_size(), not
dma_map_mapping_size().

Fixes: c93f261dfc39 ("Documentation/core-api: add swiotlb documentation")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 Documentation/core-api/swiotlb.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/core-api/swiotlb.rst b/Documentation/core-api/swiotlb.rst
index 9e0fe027dd3bd..303999f09ea03 100644
--- a/Documentation/core-api/swiotlb.rst
+++ b/Documentation/core-api/swiotlb.rst
@@ -107,7 +107,7 @@ A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE
 bytes, which is 256 KiB with current definitions. When a device's DMA settings
 are such that the device might use swiotlb, the maximum size of a DMA segment
 must be limited to that 256 KiB. This value is communicated to higher-level
-kernel code via dma_map_mapping_size() and swiotlb_max_mapping_size(). If the
+kernel code via dma_max_mapping_size() and swiotlb_max_mapping_size(). If the
 higher-level code fails to account for this limit, it may make requests that
 are too large for swiotlb, and get a "swiotlb full" error.
 
-- 
2.53.0

Re: [PATCH 4/7] docs: swiotlb: Fix maximum mapping size helper

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> The DMA helper is named dma_max_mapping_size(), not
> dma_map_mapping_size().
> 
> Fixes: c93f261dfc39 ("Documentation/core-api: add swiotlb documentation")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/swiotlb.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/swiotlb.rst b/Documentation/core-api/swiotlb.rst
> index 9e0fe027dd3bd..303999f09ea03 100644
> --- a/Documentation/core-api/swiotlb.rst
> +++ b/Documentation/core-api/swiotlb.rst
> @@ -107,7 +107,7 @@ A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE
>  bytes, which is 256 KiB with current definitions. When a device's DMA settings
>  are such that the device might use swiotlb, the maximum size of a DMA segment
>  must be limited to that 256 KiB. This value is communicated to higher-level
> -kernel code via dma_map_mapping_size() and swiotlb_max_mapping_size(). If the
> +kernel code via dma_max_mapping_size() and swiotlb_max_mapping_size(). If the
>  higher-level code fails to account for this limit, it may make requests that
>  are too large for swiotlb, and get a "swiotlb full" error.
>  

-- 
~Randy

[PATCH 5/7] docs: this_cpu_ops: Fix SRCU helper names

[Karl Mehltretter]

Use the actual srcu_read_lock_nmisafe() and atomic_long_inc()
helper names.

Fixes: df0cee43114b ("docs: Improve discussion of this_cpu_ptr(), add raw_cpu_ptr()")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 Documentation/core-api/this_cpu_ops.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
index 533ac5dd57507..367706d1714b1 100644
--- a/Documentation/core-api/this_cpu_ops.rst
+++ b/Documentation/core-api/this_cpu_ops.rst
@@ -150,10 +150,10 @@ preemptible code are addressed by raw_cpu_ptr(), but such use cases need
 to handle cases where two different CPUs are accessing the same per cpu
 variable, which might well be that of a third CPU.  These use cases are
 typically performance optimizations.  For example, SRCU implements a pair
-of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe()
+of counters as a pair of per-CPU variables, and srcu_read_lock_nmisafe()
 uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses
-atomic_inc_long() to handle migration between the raw_cpu_ptr() and
-the atomic_inc_long().
+atomic_long_inc() to handle migration between the raw_cpu_ptr() and
+the atomic_long_inc().
 
 Per cpu variables and offsets
 -----------------------------
-- 
2.53.0

Re: [PATCH 5/7] docs: this_cpu_ops: Fix SRCU helper names

[Paul E. McKenney]

On Sat, Aug 22, 2026 at 02:16:49PM +0200, Karl Mehltretter wrote:
> Use the actual srcu_read_lock_nmisafe() and atomic_long_inc()
> helper names.
> 
> Fixes: df0cee43114b ("docs: Improve discussion of this_cpu_ptr(), add raw_cpu_ptr()")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Paul E. McKenney <paulmck@kernel.org>

> ---
>  Documentation/core-api/this_cpu_ops.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
> index 533ac5dd57507..367706d1714b1 100644
> --- a/Documentation/core-api/this_cpu_ops.rst
> +++ b/Documentation/core-api/this_cpu_ops.rst
> @@ -150,10 +150,10 @@ preemptible code are addressed by raw_cpu_ptr(), but such use cases need
>  to handle cases where two different CPUs are accessing the same per cpu
>  variable, which might well be that of a third CPU.  These use cases are
>  typically performance optimizations.  For example, SRCU implements a pair
> -of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe()
> +of counters as a pair of per-CPU variables, and srcu_read_lock_nmisafe()
>  uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses
> -atomic_inc_long() to handle migration between the raw_cpu_ptr() and
> -the atomic_inc_long().
> +atomic_long_inc() to handle migration between the raw_cpu_ptr() and
> +the atomic_long_inc().
>  
>  Per cpu variables and offsets
>  -----------------------------
> -- 
> 2.53.0
> 

Re: [PATCH 5/7] docs: this_cpu_ops: Fix SRCU helper names

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> Use the actual srcu_read_lock_nmisafe() and atomic_long_inc()
> helper names.
> 
> Fixes: df0cee43114b ("docs: Improve discussion of this_cpu_ptr(), add raw_cpu_ptr()")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/this_cpu_ops.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst
> index 533ac5dd57507..367706d1714b1 100644
> --- a/Documentation/core-api/this_cpu_ops.rst
> +++ b/Documentation/core-api/this_cpu_ops.rst
> @@ -150,10 +150,10 @@ preemptible code are addressed by raw_cpu_ptr(), but such use cases need
>  to handle cases where two different CPUs are accessing the same per cpu
>  variable, which might well be that of a third CPU.  These use cases are
>  typically performance optimizations.  For example, SRCU implements a pair
> -of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe()
> +of counters as a pair of per-CPU variables, and srcu_read_lock_nmisafe()
>  uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses
> -atomic_inc_long() to handle migration between the raw_cpu_ptr() and
> -the atomic_inc_long().
> +atomic_long_inc() to handle migration between the raw_cpu_ptr() and
> +the atomic_long_inc().
>  
>  Per cpu variables and offsets
>  -----------------------------

-- 
~Randy

Re: [PATCH 6/7] docs: xarray: Fix xas_try_split() name

[Zi Yan]

On Sat Aug 22, 2026 at 8:16 AM EDT, Karl Mehltretter wrote:
> The iterative split helper is xas_try_split(), not
> xas_try_alloc().
>
> Fixes: 3fec86f8aa8c ("xarray: add xas_try_split() to split a multi-index entry")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
>  Documentation/core-api/xarray.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks.

Reviewed-by: Zi Yan <ziy@nvidia.com>

>
> diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst
> index c6c91cbd0c3ce..3d2b20c05a937 100644
> --- a/Documentation/core-api/xarray.rst
> +++ b/Documentation/core-api/xarray.rst
> @@ -490,7 +490,7 @@ entry at every index to ``NULL`` and dissolve the tie.  A multi-index
>  entry can be split into entries occupying smaller ranges by calling
>  xas_split_alloc() without the xa_lock held, followed by taking the lock
>  and calling xas_split() or calling xas_try_split() with xa_lock. The
> -difference between xas_split_alloc()+xas_split() and xas_try_alloc() is
> +difference between xas_split_alloc()+xas_split() and xas_try_split() is
>  that xas_split_alloc() + xas_split() split the entry from the original
>  order to the new order in one shot uniformly, whereas xas_try_split()
>  iteratively splits the entry containing the index non-uniformly.




-- 
Best Regards,
Yan, Zi

Re: [PATCH 6/7] docs: xarray: Fix xas_try_split() name

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> The iterative split helper is xas_try_split(), not
> xas_try_alloc().
> 
> Fixes: 3fec86f8aa8c ("xarray: add xas_try_split() to split a multi-index entry")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/xarray.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst
> index c6c91cbd0c3ce..3d2b20c05a937 100644
> --- a/Documentation/core-api/xarray.rst
> +++ b/Documentation/core-api/xarray.rst
> @@ -490,7 +490,7 @@ entry at every index to ``NULL`` and dissolve the tie.  A multi-index
>  entry can be split into entries occupying smaller ranges by calling
>  xas_split_alloc() without the xa_lock held, followed by taking the lock
>  and calling xas_split() or calling xas_try_split() with xa_lock. The
> -difference between xas_split_alloc()+xas_split() and xas_try_alloc() is
> +difference between xas_split_alloc()+xas_split() and xas_try_split() is
>  that xas_split_alloc() + xas_split() split the entry from the original
>  order to the new order in one shot uniformly, whereas xas_try_split()
>  iteratively splits the entry containing the index non-uniformly.

-- 
~Randy

Re: [PATCH 7/7] docs: debugobjects: Fix debug_object_init() name

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> The initialization helper is debug_object_init(), not
> debug_objects_init().
> 
> Fixes: 691cc54c7d28 ("debugobjects: add documentation")
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

> ---
>  Documentation/core-api/debug-objects.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/debug-objects.rst b/Documentation/core-api/debug-objects.rst
> index ac926fd55a64a..708775fc581b7 100644
> --- a/Documentation/core-api/debug-objects.rst
> +++ b/Documentation/core-api/debug-objects.rst
> @@ -129,7 +129,7 @@ When the real object is not yet tracked by debugobjects then the
>  fixup_activate function is called if available. This is necessary to
>  allow the legitimate activation of statically allocated and initialized
>  objects. The fixup function checks whether the object is valid and calls
> -the debug_objects_init() function to initialize the tracking of this
> +the debug_object_init() function to initialize the tracking of this
>  object.
>  
>  When the activation is legitimate, then the state of the associated

-- 
~Randy