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: <F12301F7-EE8E-4B5A-BE28-17A235DBCA7E@lairdtech.com>
Date:	Mon, 21 Dec 2015 22:00:40 +0000
From:	Dan Kephart <Dan.Kephart@...rdtech.com>
To:	Souptick Joarder <jrdr.linux@...il.com>,
	Brent Taylor <motobud@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kalle Valo <kvalo@....qualcomm.com>,
	"ath6kl@...ts.infradead.org" <ath6kl@...ts.infradead.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ath6kl: Use vmalloc to allocate ar->fw for api1 method

Hi Brent and Souptick,




On 12/21/15, 2:23 PM, "ath6kl on behalf of Souptick Joarder" <ath6kl-bounces@...ts.infradead.org on behalf of jrdr.linux@...il.com> wrote:

>Hi Brent,
>
>On Tue, Dec 1, 2015 at 11:11 AM, Brent Taylor <motobud@...il.com> wrote:
>> Since commit 8437754c83351d6213c1a47ff029c1126d6042a7, ar->fw is expected to be pointing to memory allocated by vmalloc.  If the api1 method (via ath6kl_fetch_fw_api1) is used to allocate memory for ar->fw, then kmemdup is used.  This patch checks if the firmware being loaded is the 'fw' image, then use vmalloc, otherwise use kmalloc.
>>
>> Signed-off-by: Brent Taylor <motobud@...il.com>
>> ---
>>  drivers/net/wireless/ath/ath6kl/init.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
>> index 6ae0734..4f2b124d 100644
>> --- a/drivers/net/wireless/ath/ath6kl/init.c
>> +++ b/drivers/net/wireless/ath/ath6kl/init.c
>> @@ -673,10 +673,15 @@ static int ath6kl_get_fw(struct ath6kl *ar, const char *filename,
>>                 return ret;
>>
>>         *fw_len = fw_entry->size;
>> -       *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
>> +   if (&ar->fw == fw)
>> +               *fw = vmalloc(fw_entry->size);
>> +   else
>> +               *fw = kmalloc(fw_entry->size, GFP_KERNEL);
>
>          Why vmalloc and kmalloc both are required? can't use either
>vmalloc or kmalloc?

My guess is the reason to use both vmalloc and kmalloc is that the firmware blob can be near 128KB.  I know our ar6003 firmwares approach that.  So vmalloc must have been chosen to avoid any issues if it was greater than 128KB.  So kmalloc is used for all the small firmware pieces (board data, otp.bin, etc) but vmalloc for the firmware itself.  

I personally fixed this issue for loading the firmware (but not board data, opt.bin, etc) in the api1 and testmode functions by have it call a new helper function:

static int ath6kl_get_fw_vm(struct ath6kl *ar, const char *filename,
			 u8 **fw, size_t *fw_len)
{
	const struct firmware *fw_entry;
	int ret;

	ret = request_firmware(&fw_entry, filename, ar->dev);
	if (ret)
	return ret;

	*fw_len = fw_entry->size;
	*fw = vmalloc(*fw_len);

	if (*fw == NULL)
	ret = -ENOMEM;

	memcpy(*fw, fw_entry->data, *fw_len);

	release_firmware(fw_entry);

	return ret;
}



>>
>>         if (*fw == NULL)
>>                 ret = -ENOMEM;
>> +       else
>> +               memcpy(*fw, fw_entry->data, fw_entry->size);
>>
>>         release_firmware(fw_entry);
>>
>> --
>> 2.6.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>-Souptick
>
>_______________________________________________
>ath6kl mailing list
>ath6kl@...ts.infradead.org
>http://lists.infradead.org/mailman/listinfo/ath6kl

- Dan Kephart

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ