[PATCH RESEND] clk: nuvoton: ma35d1-divider: simplify allocation

[PATCH RESEND] clk: nuvoton: ma35d1-divider: simplify allocation

[Rosen Penev]

Use a flexible array member instead of kcalloc + pointer that is not
actually const.

Simplifies allocation slightly.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/clk/nuvoton/clk-ma35d1-divider.c | 20 +++++++-------------
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/nuvoton/clk-ma35d1-divider.c b/drivers/clk/nuvoton/clk-ma35d1-divider.c
index e992e7c30341..6eaca5b35dd8 100644
--- a/drivers/clk/nuvoton/clk-ma35d1-divider.c
+++ b/drivers/clk/nuvoton/clk-ma35d1-divider.c
@@ -17,9 +17,9 @@ struct ma35d1_adc_clk_div {
 	u8 shift;
 	u8 width;
 	u32 mask;
-	const struct clk_div_table *table;
 	/* protects concurrent access to clock divider registers */
 	spinlock_t *lock;
+	struct clk_div_table table[];
 };
 
 static inline struct ma35d1_adc_clk_div *to_ma35d1_adc_clk_div(struct clk_hw *_hw)
@@ -83,30 +83,25 @@ struct clk_hw *ma35d1_reg_adc_clkdiv(struct device *dev, const char *name,
 {
 	struct ma35d1_adc_clk_div *div;
 	struct clk_init_data init;
-	struct clk_div_table *table;
 	struct clk_parent_data pdata = { .index = 0 };
 	u32 max_div, min_div;
 	struct clk_hw *hw;
 	int ret;
 	int i;
 
-	div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
-	if (!div)
-		return ERR_PTR(-ENOMEM);
-
 	max_div = clk_div_mask(width) + 1;
 	min_div = 1;
 
-	table = devm_kcalloc(dev, max_div + 1, sizeof(*table), GFP_KERNEL);
-	if (!table)
+	div = devm_kzalloc(dev, struct_size(div, table, max_div + 1), GFP_KERNEL);
+	if (!div)
 		return ERR_PTR(-ENOMEM);
 
 	for (i = 0; i < max_div; i++) {
-		table[i].val = min_div + i;
-		table[i].div = 2 * table[i].val;
+		div->table[i].val = min_div + i;
+		div->table[i].div = 2 * div->table[i].val;
 	}
-	table[max_div].val = 0;
-	table[max_div].div = 0;
+	div->table[max_div].val = 0;
+	div->table[max_div].div = 0;
 
 	memset(&init, 0, sizeof(init));
 	init.name = name;
@@ -122,7 +117,6 @@ struct clk_hw *ma35d1_reg_adc_clkdiv(struct device *dev, const char *name,
 	div->mask = mask_bit ? BIT(mask_bit) : 0;
 	div->lock = lock;
 	div->hw.init = &init;
-	div->table = table;
 
 	hw = &div->hw;
 	ret = devm_clk_hw_register(dev, hw);
-- 
2.55.0

Re: [PATCH RESEND] clk: nuvoton: ma35d1-divider: simplify allocation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Out-of-bounds bitwise shift due to evaluating BIT(mask_bit) with mask_bit = 0x1ffff.
- [High] Massive 1MB contiguous memory allocation and O(N) linear search for a simple linear clock divider.
--

commit c433ecbdd759eecab477bbeefb42c04e4a53b527
Author: Rosen Penev <rosenp@gmail.com>

clk: nuvoton: ma35d1-divider: simplify allocation

This commit simplifies the allocation in the ma35d1-divider driver by replacing
a separate kcalloc for the clock divider table with a flexible array member.

> diff --git a/drivers/clk/nuvoton/clk-ma35d1-divider.c b/drivers/clk/nuvoton/clk-ma35d1-divider.c
> index e992e7c303419..6eaca5b35dd8c 100644
> --- a/drivers/clk/nuvoton/clk-ma35d1-divider.c
> +++ b/drivers/clk/nuvoton/clk-ma35d1-divider.c
[ ... ]
> @@ -83,30 +83,25 @@ struct clk_hw *ma35d1_reg_adc_clkdiv(struct device *dev, const char *name,
[ ... ]
>  	max_div = clk_div_mask(width) + 1;
>  	min_div = 1;
>  
> -	table = devm_kcalloc(dev, max_div + 1, sizeof(*table), GFP_KERNEL);
> -	if (!table)
> +	div = devm_kzalloc(dev, struct_size(div, table, max_div + 1), GFP_KERNEL);

[Severity: High]
This isn't a bug introduced by this patch, but does this allocation request an
excessively large amount of contiguous memory?

In ma35d1_clocks_probe() from drivers/clk/nuvoton/clk-ma35d1.c, this function
is called with width set to 17:

    hws[ADC_DIV] = ma35d1_reg_adc_clkdiv(dev, "adc_div", hws[PCLK0],
                                         &ma35d1_lock, 0,
                                         clk_base + REG_CLK_CLKDIV4,
                                         4, 17, 0x1ffff);

With width = 17, max_div becomes 131,072. The struct_size() calculation
requests an array of 131,073 struct clk_div_table elements. At 8 bytes per
element, this results in an order-8 allocation of slightly over 1MB.

Contiguous allocations of this size using devm_kzalloc() with GFP_KERNEL
are highly vulnerable to fragmentation and can frequently fail on long-running
systems.

Additionally, passing this massive table to generic clock helpers like
divider_recalc_rate() and divider_determine_rate() causes an O(N) linear
search over all 131,073 entries on every rate query. Could this be optimized
to avoid generating the entire table in memory?

> +	if (!div)
>  		return ERR_PTR(-ENOMEM);
>  
[ ... ]
> @@ -122,7 +117,6 @@ struct clk_hw *ma35d1_reg_adc_clkdiv(struct device *dev, const char *name,
>  	div->mask = mask_bit ? BIT(mask_bit) : 0;

[Severity: High]
This is a pre-existing issue, but does evaluating BIT(mask_bit) here cause
an out-of-bounds shift?

When ma35d1_clocks_probe() calls ma35d1_reg_adc_clkdiv(), it passes 0x1ffff
(131071) as the mask_bit parameter. Evaluating BIT(131071) triggers undefined
behavior in C. 

On architectures like ARM64, this modulo-shifts into 1UL << 63, which truncates
to 0 when stored in the u32 mask, or 1UL << 31 on 32-bit systems.

Since this is used to populate the hardware register mask in
ma35d1_clkdiv_set_rate(), does this result in a corrupted clock configuration
mask?

>  	div->lock = lock;
>  	div->hw.init = &init;
> -	div->table = table;
>  
>  	hw = &div->hw;
>  	ret = devm_clk_hw_register(dev, hw);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912002326.237419-1-rosenp@gmail.com?part=1