* [PATCH] irqdesc: Fail check on early_irq_init allocation.
@ 2023-11-11 17:00 Paran Lee
2023-11-12 14:00 ` Marc Zyngier
0 siblings, 1 reply; 5+ messages in thread
From: Paran Lee @ 2023-11-11 17:00 UTC (permalink / raw)
To: Thomas Gleixner, Marc Zyngier
Cc: linux-kernel, shjy180909, austindh.kim, Paran Lee
When doing start_kernel(),
On early_irq_init(), alloc_desc() or alloc_percpu()
may be fails. So, Explicit fail check needed on dynamic allocation.
Signed-off-by: Paran Lee <p4ranlee@gmail.com>
---
kernel/irq/irqdesc.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 27ca1c866f29..bdc35823e4c4 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -565,6 +565,7 @@ int __init early_irq_init(void)
for (i = 0; i < initcnt; i++) {
desc = alloc_desc(i, node, 0, NULL, NULL);
+ BUG_ON(!desc);
irq_insert_desc(i, desc);
}
return arch_early_irq_init();
@@ -582,18 +583,16 @@ struct irq_desc irq_desc[NR_IRQS] __cacheline_aligned_in_smp = {
int __init early_irq_init(void)
{
- int count, i, node = first_online_node;
- struct irq_desc *desc;
+ int count = ARRAY_SIZE(irq_desc), i, node = first_online_node;
+ struct irq_desc *desc = irq_desc;
init_irq_default_affinity();
printk(KERN_INFO "NR_IRQS: %d\n", NR_IRQS);
- desc = irq_desc;
- count = ARRAY_SIZE(irq_desc);
-
for (i = 0; i < count; i++) {
desc[i].kstat_irqs = alloc_percpu(unsigned int);
+ BUG_ON(!desc[i].kstat_irqs);
alloc_masks(&desc[i], node);
raw_spin_lock_init(&desc[i].lock);
lockdep_set_class(&desc[i].lock, &irq_desc_lock_class);
--
2.25.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] irqdesc: Fail check on early_irq_init allocation.
2023-11-11 17:00 [PATCH] irqdesc: Fail check on early_irq_init allocation Paran Lee
@ 2023-11-12 14:00 ` Marc Zyngier
2023-11-12 14:19 ` Paran Lee
0 siblings, 1 reply; 5+ messages in thread
From: Marc Zyngier @ 2023-11-12 14:00 UTC (permalink / raw)
To: Paran Lee; +Cc: Thomas Gleixner, linux-kernel, shjy180909, austindh.kim
On Sat, 11 Nov 2023 17:00:36 +0000,
Paran Lee <p4ranlee@gmail.com> wrote:
>
> When doing start_kernel(),
> On early_irq_init(), alloc_desc() or alloc_percpu()
> may be fails. So, Explicit fail check needed on dynamic allocation.
A failing allocation already results in a massive splat describing how
the allocation failed. Further use of the NULL pointer will also
result in a terminal oops, particularly if this happens this early in
the boot sequence.
So what do these BUG_ON() calls buy us?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] irqdesc: Fail check on early_irq_init allocation.
2023-11-12 14:00 ` Marc Zyngier
@ 2023-11-12 14:19 ` Paran Lee
2023-11-12 15:08 ` Marc Zyngier
0 siblings, 1 reply; 5+ messages in thread
From: Paran Lee @ 2023-11-12 14:19 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Thomas Gleixner, linux-kernel, shjy180909, austindh.kim
On 2023-11-12 오후 11:00, Marc Zyngier wrote:
Thanks for the code review Marc!
I think function alloc_descs() in irqdesc.c has also alloc_desc() fail
handling, and there's kernel-wide code consistency checking for
allocation failures, and I thought it would be nice to mark it.
So that the code is aware of it.
Even if it panics with a null derefence reference.
> A failing allocation already results in a massive splat describing how
> the allocation failed. Further use of the NULL pointer will also
> result in a terminal oops, particularly if this happens this early in
> the boot sequence.
>
> So what do these BUG_ON() calls buy us?
>
> M.
>
If anyone has any ideas on how to get a little fancier with the allocation,
I'll send a v2 patch in that direction.
BR
Paran Lee
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] irqdesc: Fail check on early_irq_init allocation.
2023-11-12 14:19 ` Paran Lee
@ 2023-11-12 15:08 ` Marc Zyngier
2023-11-12 15:21 ` Paran Lee
0 siblings, 1 reply; 5+ messages in thread
From: Marc Zyngier @ 2023-11-12 15:08 UTC (permalink / raw)
To: Paran Lee; +Cc: Thomas Gleixner, linux-kernel, shjy180909, austindh.kim
On Sun, 12 Nov 2023 14:19:28 +0000,
Paran Lee <p4ranlee@gmail.com> wrote:
> On 2023-11-12 오후 11:00, Marc Zyngier wrote:
>
> Thanks for the code review Marc!
>
> I think function alloc_descs() in irqdesc.c has also alloc_desc() fail
> handling, and there's kernel-wide code consistency checking for
> allocation failures, and I thought it would be nice to mark it.
alloc_descs() and early_irq_init() are very different beasts. The
former can be used *at any time* over the kernel's lifetime, while the
latter is only used *once*. This makes a whole lot a difference, don't
you think?
> So that the code is aware of it.
>
> Even if it panics with a null derefence reference.
Don't you think it is a bit pointless to trade a fatal error for
another one?
>
> > A failing allocation already results in a massive splat describing how
> > the allocation failed. Further use of the NULL pointer will also
> > result in a terminal oops, particularly if this happens this early in
> > the boot sequence.
> >
> > So what do these BUG_ON() calls buy us?
> >
> > M.
> >
>
> If anyone has any ideas on how to get a little fancier with the allocation,
> I'll send a v2 patch in that direction.
It's not about being fancy. It is about being useful. Your BUG_ON()s
are not making things any better for early allocation failures.
A much better idea would be to *get rid* of early allocation failures
altogether, by moving all architectures to SPARSE_IRQ and making sure
that NR_LEGAY_IRQ is always zero, meaning there is nothing to
allocate. That would be something useful.
But adding random BUG_ON() based on the dogma that all allocations
must be checked doesn't bring value to the kernel as a whole.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] irqdesc: Fail check on early_irq_init allocation.
2023-11-12 15:08 ` Marc Zyngier
@ 2023-11-12 15:21 ` Paran Lee
0 siblings, 0 replies; 5+ messages in thread
From: Paran Lee @ 2023-11-12 15:21 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Thomas Gleixner, linux-kernel, shjy180909, austindh.kim
On 2023-11-13 오전 12:08, Marc Zyngier wrote:
Thanks for the great feedback Marc!
The review has taught me a lot of things I didn't realized
I'll try to do better in the direction you suggested. To be useful.
> A much better idea would be to *get rid* of early allocation failures
> altogether, by moving all architectures to SPARSE_IRQ and making sure
> that NR_LEGAY_IRQ is always zero, meaning there is nothing to
> allocate. That would be something useful.
>
> But adding random BUG_ON() based on the dogma that all allocations
> must be checked doesn't bring value to the kernel as a whole.
>
> M.
Thanks so much!
BR
Paran Lee
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-12 15:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-11 17:00 [PATCH] irqdesc: Fail check on early_irq_init allocation Paran Lee
2023-11-12 14:00 ` Marc Zyngier
2023-11-12 14:19 ` Paran Lee
2023-11-12 15:08 ` Marc Zyngier
2023-11-12 15:21 ` Paran Lee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox