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

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.

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

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.

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