From: Markus Elfring <[email protected]>
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 <[email protected]>
---
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
On 8/27/17 3:26 PM, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
> 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 <[email protected]>
> ---
> 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);
>
>
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 <[email protected]>
> > 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
> 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
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 <[email protected]>
>>> 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.
Hi everyone
27.08.2017, 22:25, "SF Markus Elfring" <[email protected]>:
> From: Markus Elfring <[email protected]>
> 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 <[email protected]>
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 <[email protected]>
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