[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrYRIPYv8euBkStd@arm.com>
Date: Fri, 9 Aug 2024 13:52:48 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Will Deacon <will@...nel.org>
Cc: Hanjun Guo <guohanjun@...wei.com>, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Sudeep Holla <sudeep.holla@....com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v1 1/1] ACPI/IORT: Switch to use kmemdup_array()
On Fri, Aug 09, 2024 at 03:16:34PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 14, 2024 at 08:54:39AM +0800, Hanjun Guo wrote:
> > +Cc Catalin
> >
> > On 2024/6/11 18:42, Hanjun Guo wrote:
> > > On 2024/6/7 0:50, Andy Shevchenko wrote:
> > > > Let the kememdup_array() take care about multiplication and possible
> > > > overflows.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > > > ---
> > > > drivers/acpi/arm64/iort.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > > > index c0b1c2c19444..e596dff20f1e 100644
> > > > --- a/drivers/acpi/arm64/iort.c
> > > > +++ b/drivers/acpi/arm64/iort.c
> > > > @@ -822,7 +822,7 @@ static struct iommu_iort_rmr_data *iort_rmr_alloc(
> > > > return NULL;
> > > > /* Create a copy of SIDs array to associate with this rmr_data */
> > > > - sids_copy = kmemdup(sids, num_sids * sizeof(*sids), GFP_KERNEL);
> > > > + sids_copy = kmemdup_array(sids, num_sids, sizeof(*sids),
> > > > GFP_KERNEL);
> > > > if (!sids_copy) {
> > > > kfree(rmr_data);
> > > > return NULL;
> > >
> > > Looks good to me,
> > >
> > > Acked-by: Hanjun Guo <guohanjun@...wei.com>
> >
> > Catalin, would you mind pick this up as well?
>
> Any news?
>
> I do not see this even in Linux Next...
Ah, sorry, I missed this. Since it doesn't look like a fix, I guess it's
fine to go in 6.12. Adding Will since he's handling the upcoming merging
window.
--
Catalin
Powered by blists - more mailing lists