Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1469959 > unrolled thread

[PATCH 1/2] sparc: Use kmalloc_array() in three functions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 1/2] sparc: Use kmalloc_array() in three functions SF Markus Elfring <elfring@users.sourceforge.net> - 2016-08-25 10:30 +0200
    Re: [PATCH 1/2] sparc: Use kmalloc_array() in three functions Paolo Bonzini <pbonzini@redhat.com> - 2016-08-29 11:50 +0200
      Re: [PATCH 1/2] sparc: Use kmalloc_array() in three functions SF Markus Elfring <elfring@users.sourceforge.net> - 2016-08-29 12:40 +0200
      Re: [PATCH 1/2] sparc: Use kmalloc_array() in three functions walter harms <wharms@bfs.de> - 2016-08-29 14:00 +0200
        Re: [PATCH 1/2] sparc: Use kmalloc_array() in three functions Paolo Bonzini <pbonzini@redhat.com> - 2016-08-29 18:50 +0200

#1469959 — [PATCH 1/2] sparc: Use kmalloc_array() in three functions

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 25 Aug 2016 09:52:44 +0200

* Multiplications for the size determination of memory allocations
  indicated that array data structures should be processed.
  Thus reuse the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

* Replace the specifications of data types by pointer dereferences
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 arch/sparc/kernel/led.c          | 2 +-
 arch/sparc/kernel/nmi.c          | 4 +++-
 arch/sparc/kernel/sys_sparc_64.c | 6 ++++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/led.c b/arch/sparc/kernel/led.c
index 3ae36f3..7444e4a 100644
--- a/arch/sparc/kernel/led.c
+++ b/arch/sparc/kernel/led.c
@@ -69,7 +69,7 @@ static ssize_t led_proc_write(struct file *file, const char __user *buffer,
 	if (count > LED_MAX_LENGTH)
 		count = LED_MAX_LENGTH;
 
-	buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
+	buf = kmalloc_array(count + 1, sizeof(*buf), GFP_KERNEL);
 	if (!buf)
 		return -ENOMEM;
 
diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index a9973bb..b88e97b 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -166,7 +166,9 @@ static int __init check_nmi_watchdog(void)
 	if (!atomic_read(&nmi_active))
 		return 0;
 
-	prev_nmi_count = kmalloc(nr_cpu_ids * sizeof(unsigned int), GFP_KERNEL);
+	prev_nmi_count = kmalloc_array(nr_cpu_ids,
+				       sizeof(*prev_nmi_count),
+				       GFP_KERNEL);
 	if (!prev_nmi_count) {
 		err = -ENOMEM;
 		goto error;
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index fe8b8ee..25b7a14 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -580,8 +580,10 @@ SYSCALL_DEFINE5(utrap_install, utrap_entry_t, type,
 			unsigned long *p = current_thread_info()->utraps;
 
 			current_thread_info()->utraps =
-				kmalloc((UT_TRAP_INSTRUCTION_31+1)*sizeof(long),
-					GFP_KERNEL);
+				kmalloc_array(UT_TRAP_INSTRUCTION_31 + 1,
+					      sizeof(*current_thread_info()
+						     ->utraps),
+					      GFP_KERNEL);
 			if (!current_thread_info()->utraps) {
 				current_thread_info()->utraps = p;
 				return -ENOMEM;
-- 
2.9.3

[toc] | [next] | [standalone]

#1471679

On 25/08/2016 10:22, SF Markus Elfring wrote:
> --- a/arch/sparc/kernel/led.c
> +++ b/arch/sparc/kernel/led.c
> @@ -69,7 +69,7 @@ static ssize_t led_proc_write(struct file *file, const char __user *buffer,
>  	if (count > LED_MAX_LENGTH)
>  		count = LED_MAX_LENGTH;
>  
> -	buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
> +	buf = kmalloc_array(count + 1, sizeof(*buf), GFP_KERNEL);
>  	if (!buf)
>  		return -ENOMEM;
>  

Here it's probably best to just remove sizeof(char) completely, as it's
1 by definition.

Paolo

[toc] | [prev] | [next] | [standalone]

#1471706

>> @@ -69,7 +69,7 @@ static ssize_t led_proc_write(struct file *file, const char __user *buffer,
>>  	if (count > LED_MAX_LENGTH)
>>  		count = LED_MAX_LENGTH;
>>  
>> -	buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
>> +	buf = kmalloc_array(count + 1, sizeof(*buf), GFP_KERNEL);
>>  	if (!buf)
>>  		return -ENOMEM;
>>  
> 
> Here it's probably best to just remove sizeof(char) completely,
> as it's 1 by definition.

Would you like to be prepared anyhow that the shown buffer variable
could eventually store other data than ordinary single byte characters?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]

#1471750

Am 29.08.2016 11:47, schrieb Paolo Bonzini:
> 
> 
> On 25/08/2016 10:22, SF Markus Elfring wrote:
>> --- a/arch/sparc/kernel/led.c
>> +++ b/arch/sparc/kernel/led.c
>> @@ -69,7 +69,7 @@ static ssize_t led_proc_write(struct file *file, const char __user *buffer,
>>  	if (count > LED_MAX_LENGTH)
>>  		count = LED_MAX_LENGTH;
>>  
>> -	buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
>> +	buf = kmalloc_array(count + 1, sizeof(*buf), GFP_KERNEL);
>>  	if (!buf)
>>  		return -ENOMEM;
>>  
> 
> Here it's probably best to just remove sizeof(char) completely, as it's
> 1 by definition.
> 
> Paolo


I would not do so, if you ever change buf to something else it would break,
having a sizeof(*buf) here is harmless and a known pattern.

re,
 wh

[toc] | [prev] | [next] | [standalone]

#1471984

On 29/08/2016 13:57, walter harms wrote:
> > > -	buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
> > > +	buf = kmalloc_array(count + 1, sizeof(*buf), GFP_KERNEL);
> > >  	if (!buf)
> > >  		return -ENOMEM;
> > >  
> > 
> > Here it's probably best to just remove sizeof(char) completely, as it's
> > 1 by definition.
> 
> I would not do so, if you ever change buf to something else it would break,
> having a sizeof(*buf) here is harmless and a known pattern.

Fair enough, it's not code I maintain.

Paolo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web