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

[sashiko-bot@kernel.org]

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