[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c00c6b13-9048-ead1-0535-f8c9e8fab240@huawei.com>
Date: Fri, 9 Aug 2024 21:16:44 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: Catalin Marinas <catalin.marinas@....com>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Will Deacon <will@...nel.org>
CC: <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 2024/8/9 20:52, Catalin Marinas wrote:
> 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.
Sorry, I sent another email almost at the same time, so missed this one.
Thanks
Hanjun
Powered by blists - more mailing lists