On Wednesday 13 May 2015 13:24:15 Brian Norris wrote:
> > >
> > > static int bcm63138_nand_probe(...)
> > > {
> > > struct bcm63138_nand_soc *priv;
> > >
> > > priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > > ...
> > > return brcmnand_probe(pdev, &priv->soc);
> > > }
> >
> > That would make struct brcmnand_soc an empty structure, right?
>
> No, it still contains the function pointers for our callbacks, which is
> the entire point. I guess it's more of a 'nand_soc_ops' structure than a
> 'nand_soc' pointer now though.
>
Ah, I see.
This is fine for a small number of function pointers, but if you ever
get a structure like this with a lot of pointers, it's better to
keep them separate, so you can define the structure of function pointers
as 'static const' in the client driver, as we do for a number of
other operations.
The main advantage of that is that you don't have to assign the members
manually at run-time, but also putting them into the read-only segment
makes it harder for an attacker to overwrite a known function pointer
with a pointer to an exploit (assuming they have limited control over
writing to kernel memory).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
