From: sashiko-bot@kernel.org
To: "Peter Zijlstra" <peterz@infradead.org>,
"Bharata B Rao" <bharata@amd.com>
Cc: linux-mm@kvack.org, Jonathan.Cameron@huawei.com,
dave.hansen@intel.com, gourry@gourry.net,
mgorman@techsingularity.net, mingo@redhat.com,
raghavendra.kt@amd.com, riel@surriel.com, rientjes@google.com,
sj@kernel.org, weixugc@google.com, willy@infradead.org,
ying.huang@linux.alibaba.com, ziy@nvidia.com, dave@stgolabs.net,
nifan.cxl@gmail.com, xuezhengchu@huawei.com, yiannis@zptcorp.com,
akpm@linux-foundation.org, david@kernel.org, byungchul@sk.com,
kinseyho@google.com, joshua.hahnjy@gmail.com, yuanchu@google.com,
balbirs@nvidia.com, alok.rathore@samsung.com, shivankg@amd.com,
donettom@linux.ibm.com, xin@zytor.com, hpa@zytor.com,
luto@kernel.org, tglx@kernel.org, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, jgross@suse.com,
boris.ostrovsky@oracle.com
Subject: Re: [RFC] x86: Remove CALL_FUNCTION_VECTOR
Date: Thu, 29 Oct 2026 10:09:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-189098@kernel.org> (raw)
In-Reply-To: <20261028100930.GP2668564@noisy.programming.kicks-ass.net>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] x86/xen: memory leak of callfunc_name in xen_smp_intr_init()
- [Low] x86/xen: unused xen_call_function_interrupt() causes build failure
- [Low] x86: dead call_function tracepoints and fred_sysvec_call_function macro
--
commit a87f5828c6202eb98c865ff7619fe6fc331a81ac
Author: Peter Zijlstra <peterz@infradead.org>
x86: Remove CALL_FUNCTION_VECTOR
This commit removes CALL_FUNCTION_VECTOR and routes multi-CPU function call
IPIs through CALL_FUNCTION_SINGLE_VECTOR across native x86 APIC, FRED, IDT,
and Xen SMP paths.
> diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
> index f400cfac69a6b..d429a2720e8e7 100644
> --- a/arch/x86/include/asm/idtentry.h
> +++ b/arch/x86/include/asm/idtentry.h
> @@ -679,7 +679,6 @@ DECLARE_IDTENTRY_SYSVEC(X86_PLATFORM_IPI_VECTOR, sysvec_x86_platform_ipi);
> DECLARE_IDTENTRY(RESCHEDULE_VECTOR, sysvec_reschedule_ipi);
> DECLARE_IDTENTRY_SYSVEC(REBOOT_VECTOR, sysvec_reboot);
> DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, sysvec_call_function_single);
> -DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VECTOR, sysvec_call_function);
> #else
> # define fred_sysvec_reschedule_ipi NULL
> # define fred_sysvec_reboot NULL
[ ... ]
> diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> index 985103cab16c4..c7397816b311a 100644
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -255,15 +255,6 @@ DEFINE_IDTENTRY_SYSVEC_SIMPLE(sysvec_reschedule_ipi)
> trace_reschedule_exit(RESCHEDULE_VECTOR);
> }
>
> -DEFINE_IDTENTRY_SYSVEC(sysvec_call_function)
> -{
> - apic_eoi();
> - trace_call_function_entry(CALL_FUNCTION_VECTOR);
> - inc_irq_stat(CALL_FUNCTION);
> - generic_smp_call_function_interrupt();
> - trace_call_function_exit(CALL_FUNCTION_VECTOR);
> -}
> -
> DEFINE_IDTENTRY_SYSVEC(sysvec_call_function_single)
> {
> apic_eoi();
[Severity: Low]
Removing sysvec_call_function() in arch/x86/kernel/smp.c drops the only call
sites of trace_call_function_entry() and trace_call_function_exit(), while
DEFINE_IRQ_VECTOR_EVENT(call_function) remains in
arch/x86/include/asm/trace/irq_vectors.h:
DEFINE_IRQ_VECTOR_EVENT(call_function);
Those dead tracepoints are also still registered in
arch/x86/kernel/trace.c:osnoise_arch_register() and osnoise_arch_unregister():
ret = register_trace_call_function_entry(trace_intel_irq_entry, NULL);
if (ret)
goto out_call_function_single_exit;
ret = register_trace_call_function_exit(trace_intel_irq_exit, "call_function");
as well as in kernel/trace/rv/monitors/nrp/nrp.c:attach_vector_irq() and
kernel/trace/rv/monitors/sts/sts.c:attach_vector_irq() (and their
corresponding detach_vector_irq() functions):
rv_attach_trace_probe("nrp", call_function_entry, handle_vector_irq_entry);
rv_attach_trace_probe("sts", call_function_entry, handle_vector_irq_entry);
In addition, in arch/x86/include/asm/idtentry.h, the !CONFIG_SMP branch still
defines:
# define fred_sysvec_call_function NULL
Should the call_function tracepoint definitions, their osnoise and RV monitor
registrations, and fred_sysvec_call_function also be removed so the unused
tracepoints do not remain exported and trigger warnings when building with
UT=1?
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index 05ee0d3b0874e..d5544026ede5a 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
[ ... ]
> @@ -80,16 +73,6 @@ int xen_smp_intr_init(unsigned int cpu)
> callfunc_name = kasprintf(GFP_KERNEL, "callfunc%d", cpu);
> if (!callfunc_name)
> goto fail_mem;
> - per_cpu(xen_callfunc_irq, cpu).name = callfunc_name;
> - rc = bind_ipi_to_irqhandler(XEN_CALL_FUNCTION_VECTOR,
> - cpu,
> - xen_call_function_interrupt,
> - IRQF_PERCPU|IRQF_NOBALANCING,
> - callfunc_name,
> - NULL);
> - if (rc < 0)
> - goto fail;
> - per_cpu(xen_callfunc_irq, cpu).irq = rc;
[Severity: Medium]
Does xen_smp_intr_init() in arch/x86/xen/smp.c leak callfunc_name on every CPU
initialization under Xen?
The kasprintf() allocation for "callfunc%d" is left in place:
callfunc_name = kasprintf(GFP_KERNEL, "callfunc%d", cpu);
if (!callfunc_name)
goto fail_mem;
Because per_cpu(xen_callfunc_irq, cpu).name = callfunc_name was removed, that
buffer is never saved, so it is leaked if the subsequent VIRQ_DEBUG setup
jumps to fail_mem or fail, and is unconditionally overwritten shortly after by
the "callfuncsingle%d" allocation:
callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu);
if (!callfunc_name)
goto fail_mem;
per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name;
[Severity: Low]
Also in arch/x86/xen/smp.c, removing bind_ipi_to_irqhandler() for
XEN_CALL_FUNCTION_VECTOR in xen_smp_intr_init() leaves
xen_call_function_interrupt() without any callers:
static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id);
...
static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
{
generic_smp_call_function_interrupt();
inc_irq_stat(CALL_FUNCTION);
return IRQ_HANDLED;
}
Won't leaving this static function defined in arch/x86/xen/smp.c trigger an
unused-function warning and break the build when CONFIG_XEN=y, CONFIG_SMP=y,
and CONFIG_WERROR=y?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261028100930.GP2668564@noisy.programming.kicks-ass.net?part=1
next prev parent reply other threads:[~2026-10-29 10:10 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 5:43 [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Bharata B Rao
2026-07-28 5:43 ` [PATCH v8 1/8] mm: migrate: Allow misplaced migration without VMA Bharata B Rao
2026-09-29 22:06 ` Davidlohr Bueso
2026-07-28 5:43 ` [PATCH v8 2/8] mm: migrate: Add promote_misplaced_memcg_folios() Bharata B Rao
2026-07-30 6:34 ` Bharata B Rao
2026-09-29 22:08 ` Davidlohr Bueso
2026-07-28 5:43 ` [PATCH v8 3/8] mm: Hot page tracking and promotion - pghot Bharata B Rao
2026-07-31 16:14 ` Bharata B Rao
2026-09-27 23:25 ` Davidlohr Bueso
2026-09-28 4:14 ` Bharata B Rao
2026-07-28 5:43 ` [PATCH v8 4/8] mm: pghot: Precision mode for pghot Bharata B Rao
2026-07-31 16:27 ` Bharata B Rao
2026-07-28 5:43 ` [PATCH v8 5/8] mm: sched: move NUMA balancing tiering promotion to pghot Bharata B Rao
2026-08-03 8:23 ` Bharata B Rao
2026-07-28 5:43 ` [PATCH v8 6/8] x86/ibs: Move IBS caps definitions into its own header Bharata B Rao
2026-07-28 5:43 ` [PATCH v8 7/8] x86/mm/ibs: In-kernel driver for AMD IBS Memory Profiler Bharata B Rao
2026-10-28 10:09 ` [RFC] x86: Remove CALL_FUNCTION_VECTOR Peter Zijlstra
2026-10-28 10:21 ` Jürgen Groß
2026-10-29 10:09 ` sashiko-bot [this message]
2026-07-28 5:43 ` [PATCH v8 8/8] x86/mm/ibs: Add runtime controls for IBS memprofiler Bharata B Rao
2026-07-28 5:55 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - microbenchmark numbers Bharata B Rao
2026-07-28 5:59 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - NAS BT Bharata B Rao
2026-07-28 6:02 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - Graph500 Bharata B Rao
2026-07-28 6:05 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - redis-memtier Bharata B Rao
2026-07-28 6:17 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure - llama-bench Bharata B Rao
2026-07-28 18:14 ` [PATCH v8 0/8] mm: Hot page tracking and promotion infrastructure Andrew Morton
2026-07-28 18:24 ` Matthew Wilcox
2026-07-28 18:57 ` Gregory Price
2026-07-28 19:20 ` David Hildenbrand (Arm)
2026-07-28 19:59 ` Gregory Price
2026-07-29 11:45 ` Bharata B Rao
2026-08-10 3:38 ` Yongting Lin
2026-08-10 4:16 ` Matthew Wilcox
2026-08-10 5:35 ` Bharata B Rao
2026-08-11 7:15 ` Yongting Lin
2026-08-13 2:21 ` Gregory Price
2026-08-10 14:37 ` SJ Park
2026-08-11 6:37 ` Yongting Lin
2026-07-29 9:35 ` Bharata B Rao
2026-07-29 13:54 ` SJ Park
2026-08-04 1:23 ` SJ Park
2026-08-06 5:49 ` Bharata B Rao
2026-08-06 13:44 ` SJ Park
2026-08-10 4:46 ` Bharata B Rao
2026-08-10 14:25 ` SJ Park
2026-09-11 21:08 ` Joshua Hahn
2026-09-16 3:08 ` Bharata B Rao
2026-09-16 20:52 ` Joshua Hahn
2026-09-17 5:23 ` Bharata B Rao
2026-09-27 23:21 ` Davidlohr Bueso
2026-09-28 4:13 ` Bharata B Rao
2026-09-25 2:12 ` Davidlohr Bueso
2026-09-25 9:50 ` SJ Park
2026-09-25 16:30 ` Davidlohr Bueso
2026-09-25 16:57 ` Gregory Price
2026-09-27 15:51 ` Bharata B Rao
2026-09-29 19:56 ` Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-189098@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alok.rathore@samsung.com \
--cc=balbirs@nvidia.com \
--cc=bharata@amd.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=byungchul@sk.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=donettom@linux.ibm.com \
--cc=gourry@gourry.net \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kinseyho@google.com \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=nifan.cxl@gmail.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shivankg@amd.com \
--cc=sj@kernel.org \
--cc=tglx@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
--cc=xuezhengchu@huawei.com \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox