On Tue, 09 Jun 2026 16:08:55 +0200
"Danilo Krummrich" <[email protected]> wrote:
> On Sat Jun 6, 2026 at 10:25 PM CEST, david.laight.linux wrote:
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 75b4698d0e58..63fdfffe1a8c 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -617,10 +617,11 @@ static void platform_device_release(struct device
> > *dev)
> > struct platform_device *platform_device_alloc(const char *name, int id)
> > {
> > struct platform_object *pa;
> > + size_t len = strlen(name);
>
> This could be strlen(name) + 1 right away, which would also avoid the memcpy()
> to implicitly rely on kzalloc() zeroing the memory, where strcpy() was
> self-contained before.
I tried not to do that 'optimisation'.
Here the kzalloc() is almost certainly needed for other reasons.
There is also the issue that, in principle (but probably not in practise),
the input string might change between the strlen() and the copy.
So it is probably best practise to not rely on the '\0' still being
there when the copy is done.
>
> >
> > - pa = kzalloc(sizeof(*pa) + strlen(name) + 1, GFP_KERNEL);
> > + pa = kzalloc(sizeof(*pa) + len + 1, GFP_KERNEL);
> > if (pa) {
> > - strcpy(pa->name, name);
> > + memcpy(pa->name, name, len);
>
> But in general, what's the improvement? strlen() still operates on a
> potentially
> unbounded string?
>
> It removes the redundant strlen() calculation that is implied by the current
> code, though this may be eliminated by CSE optimization.
CSE won't eliminate it.
It probably wouldn't eliminate a second strlen(name) either.
I'm not trying to remove strlen(), just strcpy().
But not just changing them all the strscpy().
David
