linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
@ 2017-12-10 17:48 SF Markus Elfring
  2017-12-10 21:41 ` Maciej W. Rozycki
  0 siblings, 1 reply; 6+ messages in thread
From: SF Markus Elfring @ 2017-12-10 17:48 UTC (permalink / raw)
  To: linux-mips, Maciej W. Rozycki, Ralf Bächle; +Cc: LKML, kernel-janitors

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 10 Dec 2017 18:42:42 +0100

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/tc/tc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tc/tc.c b/drivers/tc/tc.c
index 3be9519654e5..2deb3768a9f6 100644
--- a/drivers/tc/tc.c
+++ b/drivers/tc/tc.c
@@ -82,10 +82,9 @@ static void __init tc_bus_add_devices(struct tc_bus *tbus)
 
 		/* Found a board, allocate it an entry in the list */
 		tdev = kzalloc(sizeof(*tdev), GFP_KERNEL);
-		if (!tdev) {
-			pr_err("tc%x: unable to allocate tc_dev\n", slot);
+		if (!tdev)
 			goto out_err;
-		}
+
 		dev_set_name(&tdev->dev, "tc%x", slot);
 		tdev->bus = tbus;
 		tdev->dev.parent = &tbus->dev;
-- 
2.15.1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
  2017-12-10 17:48 [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices() SF Markus Elfring
@ 2017-12-10 21:41 ` Maciej W. Rozycki
  2017-12-11  2:05   ` Joe Perches
  2017-12-11  8:15   ` SF Markus Elfring
  0 siblings, 2 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2017-12-10 21:41 UTC (permalink / raw)
  To: SF Markus Elfring; +Cc: linux-mips, Ralf Bächle, LKML, kernel-janitors

On Sun, 10 Dec 2017, SF Markus Elfring wrote:

> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.

 And the problem here is?

  Maciej

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
  2017-12-10 21:41 ` Maciej W. Rozycki
@ 2017-12-11  2:05   ` Joe Perches
  2017-12-11 13:17     ` Maciej W. Rozycki
  2017-12-11  8:15   ` SF Markus Elfring
  1 sibling, 1 reply; 6+ messages in thread
From: Joe Perches @ 2017-12-11  2:05 UTC (permalink / raw)
  To: Maciej W. Rozycki, SF Markus Elfring
  Cc: linux-mips, Ralf Bächle, LKML, kernel-janitors

On Sun, 2017-12-10 at 21:41 +0000, Maciej W. Rozycki wrote:
> On Sun, 10 Dec 2017, SF Markus Elfring wrote:
> 
> > Omit an extra message for a memory allocation failure in this function.
> > 
> > This issue was detected by using the Coccinelle software.
> 
>  And the problem here is?

Markus' terrible commit messages.

Generically, any OOM via a malloc like call has a dump_stack()
which shows a stack trace unless __GFP_NOWARN is used.

So this message is generally unnecessary as the dump_stack()
will show the tc_bus_add_devices function name and (now hashed)
value of the function address.

What will be different is the particular slot # of the tc_dev
will no longer be shown.

Really though, if there's an OOM on the init, there are larger
problems and the system will be unusable.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
  2017-12-10 21:41 ` Maciej W. Rozycki
  2017-12-11  2:05   ` Joe Perches
@ 2017-12-11  8:15   ` SF Markus Elfring
  1 sibling, 0 replies; 6+ messages in thread
From: SF Markus Elfring @ 2017-12-11  8:15 UTC (permalink / raw)
  To: Maciej W. Rozycki, linux-mips; +Cc: Ralf Bächle, LKML, kernel-janitors

>> Omit an extra message for a memory allocation failure in this function.
>>
>> This issue was detected by using the Coccinelle software.
> 
>  And the problem here is?

I suggest to reconsider the relevance of another error message.
Would you like to achieve a better explanation for this use case?

* Do you find the wording “WARNING: Possible unnecessary 'out of memory' message”
  from the script “checkpatch.pl” more appropriate?

* Can a default Linux allocation failure report be sufficient?

Regards,
Markus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
  2017-12-11  2:05   ` Joe Perches
@ 2017-12-11 13:17     ` Maciej W. Rozycki
  2017-12-11 13:38       ` SF Markus Elfring
  0 siblings, 1 reply; 6+ messages in thread
From: Maciej W. Rozycki @ 2017-12-11 13:17 UTC (permalink / raw)
  To: Joe Perches
  Cc: SF Markus Elfring, linux-mips, Ralf Bächle, LKML, kernel-janitors

On Sun, 10 Dec 2017, Joe Perches wrote:

> > > Omit an extra message for a memory allocation failure in this function.
> > > 
> > > This issue was detected by using the Coccinelle software.
> > 
> >  And the problem here is?
> 
> Markus' terrible commit messages.
> 
> Generically, any OOM via a malloc like call has a dump_stack()
> which shows a stack trace unless __GFP_NOWARN is used.
> 
> So this message is generally unnecessary as the dump_stack()
> will show the tc_bus_add_devices function name and (now hashed)
> value of the function address.

 Fair enough.

> What will be different is the particular slot # of the tc_dev
> will no longer be shown.
> 
> Really though, if there's an OOM on the init, there are larger
> problems and the system will be unusable.

 Well, the problem may well be the caller doing something silly, so we do 
want to have it identified, hence the extra message.  Given that, as you 
say, `kzalloc' already provides the necessary diagnostic I agree the 
message can go.

 However I would indeed prefer that a commit description is at least 
exhaustive enough for such a dumb reviewer as I am to understand what is 
going on right away.  So please make it say at least:

"Remove an extraneous message that duplicates the diagnostic already 
provided by `kzalloc' for a memory allocation failure in this function."

or suchlike in v2 for me to apply a Reviewed-by: tag.

 Thanks,

  Maciej

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices()
  2017-12-11 13:17     ` Maciej W. Rozycki
@ 2017-12-11 13:38       ` SF Markus Elfring
  0 siblings, 0 replies; 6+ messages in thread
From: SF Markus Elfring @ 2017-12-11 13:38 UTC (permalink / raw)
  To: Maciej W. Rozycki, linux-mips
  Cc: Joe Perches, Ralf Bächle, LKML, kernel-janitors

>  However I would indeed prefer that a commit description is at least 
> exhaustive enough for such a dumb reviewer as I am to understand what is 
> going on right away.

I can follow your desire in principle.


> So please make it say at least:
> 
> "Remove an extraneous message that duplicates the diagnostic already 
> provided by `kzalloc' for a memory allocation failure in this function."

How much clarification can such a wording bring to the software situation
if the desired data structures might be still unclear for “the diagnostic”?


> or suchlike in v2 for me to apply a Reviewed-by: tag.

Are you interested in a safe description for a default Linux allocation
failure report?

How do you think about corresponding reference documentation
(besides source code)?

Regards,
Markus

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-12-11 14:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-10 17:48 [PATCH] TC: Delete an error message for a failed memory allocation in tc_bus_add_devices() SF Markus Elfring
2017-12-10 21:41 ` Maciej W. Rozycki
2017-12-11  2:05   ` Joe Perches
2017-12-11 13:17     ` Maciej W. Rozycki
2017-12-11 13:38       ` SF Markus Elfring
2017-12-11  8:15   ` SF Markus Elfring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).