[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23d0939e-0a7b-f822-ae64-0cb64f6aefc2@chelsio.com>
Date: Fri, 14 Feb 2020 13:40:02 +0530
From: Vinay Kumar Yadav <vinay.yadav@...lsio.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Stephen Kitt <steve@....org>,
"David S. Miller" <davem@...emloft.net>
Cc: Atul Gupta <atul.gupta@...lsio.com>, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] crypto: chelsio - remove extra allocation for chtls_dev
Hi Herbert,
On 2/13/2020 11:17 AM, Herbert Xu wrote:
> On Fri, Jan 24, 2020 at 11:20:51PM +0100, Stephen Kitt wrote:
>> chtls_uld_add allocates room for info->nports net_device structs
>> following the chtls_dev struct, presumably because it was originally
>> intended that the ports array would be stored there. This is suggested
>> by the assignment which was present in initial versions and removed by
>> c4e848586cf1 ("crypto: chelsio - remove redundant assignment to
>> cdev->ports"):
>>
>> cdev->ports = (struct net_device **)(cdev + 1);
>>
>> This assignment was never used, being overwritten by lldi->ports
>> immediately afterwards, and I couldn't find any uses of the memory
>> allocated past the end of the struct.
>>
>> Signed-off-by: Stephen Kitt <steve@....org>
> Thanks for the patch!
>
> I think the problem goes deeper though. It appears that instead
> of allocating a ports array this function actually hangs onto the
> array from the function argument "info". This seems to be broken
> and possibly the extra memory allocated was meant to accomodate
> the ports array. Indeed, the code removed by the commit that you
> mentioned indicates this as well (although the memory was never
> actually used).
Yes, memory was never used. Author allocated port array but later
realized that he can use port array allocated by lld(cxgb4) and missed
to remove memory allocation at commit mentioned in patch. I think this
patch will correct memory allocation.
>
> Dave, I think we should talk about the maintainence of the chelsio
> net/crypto drivers. They have quite a bit of overlap and there is
> simply not enough people on the crypto side to review these drivers
> properly. Would it be possible for all future changes to these
> drivers to go through the net tree?
>
> Cheers,
Powered by blists - more mailing lists