Re: [PATCH 4/5] spi: spi-gpio: Make optional chipselect handling more explicit

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Jan 3, 2018 at 10:17 AM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> On Wed, Jan 3, 2018 at 9:58 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> On Wed, Jan 3, 2018 at 9:21 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>>
>>> Hmm, having two indicators for the same feature (spi_gpio->has_cs == true and
>>> spi_gpio->cs_gpios[0] = NULL), and the need to keep them in sync in the
>>> future, also complicates things.
>>
>> The patch does not do this.
>>
>> It removes the latter and adds the former. That is why it removes the
>> assignment of NULL to cs_gpios[0].
>
> So what is cs_gpios[0] if has_cs == true? Oh, it will point to unallocated
> memory right after the structure...

I think it is a problem with all dynamic arrays: they are prone to out-of-bounds
accesses.

That in turn comes from the following design pattern i the spi alloc_master()
helper:

        status = spi_gpio_request(pdata, dev_name(&pdev->dev), &master_flags);
        if (status < 0)
                return status;

        master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
                                        (sizeof(unsigned long) * num_devices));
        if (!master) {
                status = -ENOMEM;
                goto gpio_free;
        }
        spi_gpio = spi_master_get_devdata(master);

So someone wanted to save a slab by using this instead of allocating
the array dynamically. It's not a very admirable coding style to begin
with. I doubt the system gains much from this.

If you agree I can rewrite it to have struct gpio_desc ** and
dynamically allocate that to the number of descriptors with devm_kzalloc()
instead, that is more in line with kernel patterns and this memory
optimization anyways seems a bit overdone anyways.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html