[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0SS3cO4acfgz0iQ@black.fi.intel.com>
Date: Mon, 25 Nov 2024 17:08:13 +0200
From: Raag Jadav <raag.jadav@...el.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>, gregkh@...uxfoundation.org,
linus.walleij@...aro.org, mika.westerberg@...ux.intel.com,
broonie@...nel.org, pierre-louis.bossart@...ux.dev,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH v1 1/5] devres: Introduce devm_kmemdup_array()
On Mon, Nov 25, 2024 at 09:49:22AM +0200, Andy Shevchenko wrote:
> On Sun, Nov 24, 2024 at 07:03:36AM +0000, Dmitry Torokhov wrote:
> > On Sun, Nov 24, 2024 at 01:35:23AM +0530, Raag Jadav wrote:
> > > Introduce '_array' variant of devm_kmemdup() for the users which lack
> > > multiplication overflow check.
> >
> > I am not sure that this new helper is needed. Unlike allocators for
> > brand new objects, such as kmalloc_array(), devm_kmemdup() makes a copy
> > of already existing object, which is supposed to be a valid object and
> > therefore will have a reasonable size. So there should be no chance for
> > hitting this overflow unless the caller is completely confused and calls
> > devm_kmemdup() with random arguments (in which case all bets are off).
>
> Don't we want to have a code more robust even if all what you say applies?
> Also this makes the call consistent with zillions of others from the alloc
> family of calls in the Linux kernel.
Agree. Although shooting in the foot is never the expectation, it is
atleast better than having to debug such unexpected cases.
Raag
Powered by blists - more mailing lists