linux-kernel - Re: [PATCH v4 1/4] devres: Provide krealloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f52a1dee-70f2-e3b4-4aa2-f591d7d8063e@arm.com>
Date:   Thu, 1 Jun 2023 10:52:59 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     James Clark <james.clark@....com>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Coresight ML <coresight@...ts.linaro.org>
Subject: Re: [PATCH v4 1/4] devres: Provide krealloc_array

On 01/06/2023 10:33, Greg KH wrote:
> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>> (Removed irrelevant recipients), +Cc: coresight ml
>>
>> Hi Greg,
>>
>> On 15/05/2023 12:55, Greg KH wrote:
>>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>>
>>>>
>>>> On 13/05/2023 12:04, Greg KH wrote:
>>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>>> do their own multiplication overflow check so provide one.
>>>>>>
>>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
>>>>>> Signed-off-by: James Clark <james.clark@....com>
>>>>>> ---
>>>>>>    Documentation/driver-api/driver-model/devres.rst |  1 +
>>>>>>    include/linux/device.h                           | 11 +++++++++++
>>>>>>    2 files changed, 12 insertions(+)
>>
>> ...
>>
>>>> Maybe something could be done with some macro magic, but it would
>>>> probably end up being worse than just copying them and would affect the
>>>> real ones as well. So yeah I can't think of any easy gains either.
>>>
>>> Ok, that's good.  Given a lack of objections from others, I'll just take
>>> this through my driver core tree in a few days.
>>
>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>> that depends on this series, which I see that, is queued in your
>> driver-core-next.
>>
>> I would like to queue [1] for the next version (as there are other
>> work that depend on this, e.g., [2]). Do you have any
>> recommendations/comments on the proposal ? Are you able to share a
>> stable branch which can be merged to coresight/next and queue the
>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
> 
> You can pull from my driver-core-next branch just fine and assume it
> will be stable.  So just pull in that one commit and all should be good
> in the future.

Thanks Greg, I will give it a go

Suzuki

> 
> thanks,
> 
> greg k-h