linux-kernel - Re: [PATCH 12/36] tty/vt: consolemap: use sizeof(*pointer) instead of sizeof(type)

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: <37ced336-ac77-4c8f-1142-1f55c01383ca@suse.cz>
Date:   Tue, 7 Jun 2022 20:13:10 +0200
From:   Jiri Slaby <jslaby@...e.cz>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/36] tty/vt: consolemap: use sizeof(*pointer) instead of
 sizeof(type)

On 07. 06. 22, 16:00, Ilpo Järvinen wrote:
> On Tue, 7 Jun 2022, Jiri Slaby wrote:
> 
>> It is preferred to use sizeof(*pointer) instead of sizeof(type). First,
>> the type of the variable can change and one needs not change the former
>> (unlike the latter). Second, the latter is error-prone due to (u16),
>> (u16 *), and (u16 **) mixture here.
>>
>> Signed-off-by: Jiri Slaby <jslaby@...e.cz>
> 
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> 
> This seems fine but see the comments below which are not directly related
> to the change itself.
> 
>> ---
>>   drivers/tty/vt/consolemap.c | 23 ++++++++++++-----------
>>   1 file changed, 12 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
>> index 097ab7d01f8b..79a62dcca046 100644
>> --- a/drivers/tty/vt/consolemap.c
>> +++ b/drivers/tty/vt/consolemap.c
>> @@ -251,12 +251,12 @@ static void set_inverse_trans_unicode(struct vc_data *conp,
>>   		return;
>>   	q = p->inverse_trans_unicode;
>>   	if (!q) {
>> -		q = p->inverse_trans_unicode =
>> -			kmalloc_array(MAX_GLYPH, sizeof(u16), GFP_KERNEL);
>> +		q = p->inverse_trans_unicode = kmalloc_array(MAX_GLYPH,
>> +				sizeof(*q), GFP_KERNEL);
>>   		if (!q)
>>   			return;
>>   	}
>> -	memset(q, 0, MAX_GLYPH * sizeof(u16));
>> +	memset(q, 0, MAX_GLYPH * sizeof(*q));
> 
> Convert kmalloc_array into kcalloc and place memset() into else branch?

IMO, the way it is now is more obvious.

>> @@ -514,11 +514,12 @@ con_insert_unipair(struct uni_pagedict *p, u_short unicode, u_short fontpos)
>>   	n = UNI_ROW(unicode);
>>   	p2 = p1[n];
>>   	if (!p2) {
>> -		p2 = p1[n] = kmalloc_array(UNI_ROW_GLYPHS, sizeof(u16), GFP_KERNEL);
>> +		p2 = p1[n] = kmalloc_array(UNI_ROW_GLYPHS, sizeof(*p2),
>> +				GFP_KERNEL);
>>   		if (!p2)
>>   			return -ENOMEM;
>>   		/* No glyphs for the characters (yet) */
>> -		memset(p2, 0xff, UNI_ROW_GLYPHS * sizeof(u16));
>> +		memset(p2, 0xff, UNI_ROW_GLYPHS * sizeof(*p2));
> 
> This could have been kcalloc'ed.

Why would you zero it before setting it to 0xff?

thanks,
-- 
js
suse labs