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

Groups > linux.kernel > #1720912 > unrolled thread

[PATCH] connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()

Back to article view | Back to linux.kernel

Contents

  [PATCH] connector: Delete an error message for a failed memory  allocation in cn_queue_alloc_callback_entry() SF Markus Elfring <elfring@users.sourceforge.net> - 2017-08-27 21:30 +0200
    Re: [PATCH] connector: Delete an error message for a failed memory  allocation in cn_queue_alloc_callback_entry() "Waskiewicz Jr, Peter" <peter.waskiewicz.jr@intel.com> - 2017-08-28 01:20 +0200
      Re: [PATCH] connector: Delete an error message for a failed memory  allocation in cn_queue_alloc_callback_entry() Dan Carpenter <dan.carpenter@oracle.com> - 2017-08-28 08:10 +0200
        Re: [PATCH] connector: Delete an error message for a failed memory  allocation in cn_queue_alloc_callback_entry() "Waskiewicz Jr, Peter" <peter.waskiewicz.jr@intel.com> - 2017-08-28 16:10 +0200
      Re: connector: Delete an error message for a failed memory allocation  in cn_queue_alloc_callback_entry() SF Markus Elfring <elfring@users.sourceforge.net> - 2017-08-28 09:10 +0200
    Re: [PATCH] connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry() Evgeniy Polyakov <zbr@ioremap.net> - 2017-09-05 15:20 +0200

#1720912 — [PATCH] connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 27 Aug 2017 21:18:37 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/connector/cn_queue.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 1f8bf054d11c..e4f31d679f02 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -40,10 +40,8 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const char *name,
 	struct cn_callback_entry *cbq;
 
 	cbq = kzalloc(sizeof(*cbq), GFP_KERNEL);
-	if (!cbq) {
-		pr_err("Failed to create new callback queue.\n");
+	if (!cbq)
 		return NULL;
-	}
 
 	atomic_set(&cbq->refcnt, 1);
 
-- 
2.14.1

[toc] | [next] | [standalone]

#1720942

On 8/27/17 3:26 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 27 Aug 2017 21:18:37 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.

Did coccinelle trip on the message or the fact you weren't returning NULL?

> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>   drivers/connector/cn_queue.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
> index 1f8bf054d11c..e4f31d679f02 100644
> --- a/drivers/connector/cn_queue.c
> +++ b/drivers/connector/cn_queue.c
> @@ -40,10 +40,8 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const char *name,
>   	struct cn_callback_entry *cbq;
>   
>   	cbq = kzalloc(sizeof(*cbq), GFP_KERNEL);
> -	if (!cbq) {
> -		pr_err("Failed to create new callback queue.\n");
> +	if (!cbq)
>   		return NULL;
> -	}

Wny not:

	if (!cbq) {
		pr_err("Failed to create new callback queue.\n");
+		return NULL;
	}

>   
>   	atomic_set(&cbq->refcnt, 1);
>   
> 

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

#1721038

On Sun, Aug 27, 2017 at 11:16:06PM +0000, Waskiewicz Jr, Peter wrote:
> On 8/27/17 3:26 PM, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Sun, 27 Aug 2017 21:18:37 +0200
> > 
> > Omit an extra message for a memory allocation failure in this function.
> > 
> > This issue was detected by using the Coccinelle software.
> 
> Did coccinelle trip on the message or the fact you weren't returning NULL?
> 

You've misread the patch somehow.  The existing code has a NULL return
and it's preserved in Markus's patch.  This sort of patch is to fix a
checkpatch.pl warning.  The error message from this kzalloc() isn't going
to get printed because it's a small allocation and small allocations
always succeed in current kernels.  But probably the main reason
checkpatch complains is that kmalloc() already prints a stack trace and
a bunch of other information so the printk doesn't add anyting.
Removing it saves a little memory.

I'm mostly a fan of running checkpatch on new patches or staging and not
on old code...

regards,
dan carpenter

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

#1721642

On 8/28/17 2:06 AM, Dan Carpenter wrote:
> On Sun, Aug 27, 2017 at 11:16:06PM +0000, Waskiewicz Jr, Peter wrote:
>> On 8/27/17 3:26 PM, SF Markus Elfring wrote:
>>> From: Markus Elfring <elfring@users.sourceforge.net>
>>> Date: Sun, 27 Aug 2017 21:18:37 +0200
>>>
>>> Omit an extra message for a memory allocation failure in this function.
>>>
>>> This issue was detected by using the Coccinelle software.
>>
>> Did coccinelle trip on the message or the fact you weren't returning NULL?
>>
> 
> You've misread the patch somehow.  The existing code has a NULL return
> and it's preserved in Markus's patch.  This sort of patch is to fix a
> checkpatch.pl warning.  The error message from this kzalloc() isn't going
> to get printed because it's a small allocation and small allocations
> always succeed in current kernels.  But probably the main reason
> checkpatch complains is that kmalloc() already prints a stack trace and
> a bunch of other information so the printk doesn't add anyting.
> Removing it saves a little memory.
> 
> I'm mostly a fan of running checkpatch on new patches or staging and not
> on old code...

And this is what I get for reading the patch with a crappy 
mailer...thanks Doubtlook.

Sorry for the noise.

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

#1721103 — Re: connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()

> Did coccinelle trip on the message

I suggest to reconsider this implementation detail with the combination
of a function call like “kzalloc”.
A script for the semantic patch language can point various update candidates
out according to a source code search pattern which is similar to “OOM_MESSAGE”
in the script “checkpatch.pl”.


> or the fact you weren't returning NULL?

How does this concern fit to my update suggestion?

Regards,
Markus

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

#1726711 — Re: [PATCH] connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()

Hi everyone

27.08.2017, 22:25, "SF Markus Elfring" <elfring@users.sourceforge.net>:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 27 Aug 2017 21:18:37 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>

Looks good to me, thanks Markus.
There is virtually zero useful information in this print if we are in the situation, when kernel can not allocate
a few bytes to run connector queue.

Acked-by: Evgeniy Polyakov <zbr@ioremap.net>

kernel-janitors@ please queue this patch up

> ---
>  drivers/connector/cn_queue.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
> index 1f8bf054d11c..e4f31d679f02 100644
> --- a/drivers/connector/cn_queue.c
> +++ b/drivers/connector/cn_queue.c
> @@ -40,10 +40,8 @@ cn_queue_alloc_callback_entry(struct cn_queue_dev *dev, const char *name,
>          struct cn_callback_entry *cbq;
>
>          cbq = kzalloc(sizeof(*cbq), GFP_KERNEL);
> - if (!cbq) {
> - pr_err("Failed to create new callback queue.\n");
> + if (!cbq)
>                  return NULL;
> - }
>
>          atomic_set(&cbq->refcnt, 1);
>
> --
> 2.14.1

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web