* Question about printking [not found] <CALF0-+XX27u4rmpe8RHiy5DsbHvoYP9DWQts+rTRfEvPQG4s8Q@mail.gmail.com> @ 2013-02-02 19:30 ` Ezequiel Garcia 2013-02-02 19:43 ` Joe Perches 0 siblings, 1 reply; 3+ messages in thread From: Ezequiel Garcia @ 2013-02-02 19:30 UTC (permalink / raw) To: gregkh, Linux Kernel Mailing List, Dan Carpenter, kernelnewbies, kernel-janitors, linux-media, devel Hello, I have a quick question. I (think I) remember Greg KH reviewing some driver patch on staging mailing list, suggesting not to do this sort of printking upon an allocation request failure: ptr = kmalloc(sizeof(foo)); if (!ptr) { pr_err("Cannot allocate memory for foo\n"); return -ENOMEM; } His argue against it was that kmalloc already takes care of reporting/printking a good deal of interesting information when this happens. Is my memory right? Can someone expand a bit on this whole idea? (of abuse of printing, or futility of printing). I'm asking after seeing *a lot* of drivers doing exactly this. Thanks, -- Ezequiel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about printking 2013-02-02 19:30 ` Question about printking Ezequiel Garcia @ 2013-02-02 19:43 ` Joe Perches 2013-02-04 20:40 ` Ezequiel Garcia 0 siblings, 1 reply; 3+ messages in thread From: Joe Perches @ 2013-02-02 19:43 UTC (permalink / raw) To: Ezequiel Garcia Cc: gregkh, Linux Kernel Mailing List, Dan Carpenter, kernelnewbies, kernel-janitors, linux-media, devel On Sat, 2013-02-02 at 16:30 -0300, Ezequiel Garcia wrote: > ptr = kmalloc(sizeof(foo)); > if (!ptr) { > pr_err("Cannot allocate memory for foo\n"); > return -ENOMEM; > } > His argue against it was that kmalloc already takes care of reporting/printking > a good deal of interesting information when this happens. > Can someone expand a bit on this whole idea? (of abuse of printing, > or futility of printing). k.alloc() takes a GFP_ flag as an arg. One of those GFP flags is __GFP_NOWARN. For all failed allocs without GFP_NOWARN a message is emitted and a dump_stack is done. (see: mm/page_alloc.c warn_alloc_failed()) So, most all of these printks after k.alloc()'s are not necessary. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question about printking 2013-02-02 19:43 ` Joe Perches @ 2013-02-04 20:40 ` Ezequiel Garcia 0 siblings, 0 replies; 3+ messages in thread From: Ezequiel Garcia @ 2013-02-04 20:40 UTC (permalink / raw) To: Joe Perches Cc: gregkh, Linux Kernel Mailing List, Dan Carpenter, kernelnewbies, kernel-janitors, linux-media, devel Hi Joe, On Sat, Feb 2, 2013 at 4:43 PM, Joe Perches <joe@perches.com> wrote: > On Sat, 2013-02-02 at 16:30 -0300, Ezequiel Garcia wrote: >> ptr = kmalloc(sizeof(foo)); >> if (!ptr) { >> pr_err("Cannot allocate memory for foo\n"); >> return -ENOMEM; >> } >> His argue against it was that kmalloc already takes care of reporting/printking >> a good deal of interesting information when this happens. > >> Can someone expand a bit on this whole idea? (of abuse of printing, >> or futility of printing). > > k.alloc() takes a GFP_ flag as an arg. > > One of those GFP flags is __GFP_NOWARN. > > For all failed allocs without GFP_NOWARN > a message is emitted and a dump_stack is > done. > > (see: mm/page_alloc.c warn_alloc_failed()) > > So, most all of these printks after > k.alloc()'s are not necessary. > > Thanks for the explanation. BTW, I see you've made some patches to fix exactly this. Nice job. Regards, -- Ezequiel ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-02-04 20:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CALF0-+XX27u4rmpe8RHiy5DsbHvoYP9DWQts+rTRfEvPQG4s8Q@mail.gmail.com>
2013-02-02 19:30 ` Question about printking Ezequiel Garcia
2013-02-02 19:43 ` Joe Perches
2013-02-04 20:40 ` Ezequiel Garcia
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®