On Fri, Mar 07, 2014 at 05:04:36PM +0900, Jingoo Han wrote: > On Thursday, March 06, 2014 1:30 AM, Laurent Pinchart wrote: > > On Thursday 06 March 2014 00:17:38 Viresh Kumar wrote: > > > On 5 March 2014 19:00, Laurent Pinchart wrote: > > > > Sure, but I wasn't sure whether all error code paths in kmalloc() > > > > resulted > > > > in an OOM message. For instance, the following code path results in an > > > > allocation failure but doesn't seem to print an OOM message: > > > > > > > > kmalloc > > > > __kmalloc > > > > __do_kmalloc > > > > slab_alloc > > > > slab_should_failslab > > > > should_failslab > > > > should_fail > > > > > > > > A bit far-fetched possibly as it requires fault injection. I haven't > > > > found > > > > any other such code path, but my understanding of that code is a bit > > > > limited. > > > > > > In that case should we actually accept patches like this at all? As they > > > might be ending up removing some useful print messages? > > > > Dan has pointed out that I've missed the fail_dump() call in should_fail(). > > One could argue that fail_dump() wouldn't print any message if the fault > > injection framework has verbosity set to 0, but I suppose we can assume that > > people using the fault injection framework know what they're doing. > > > > All other error paths in kmalloc() seem to result in a message being > > printed. > > I might have missed something, but I can trust the developers who know that > > code much better than I do that kmalloc() is designed to print an error > > message in all error paths. Any failure to print a message would be a > > kmalloc() bug that should be fixed, and getting rid of the allocation error > > messages in drivers would seem like a nice cleanup to me. > > Hi Thierry Reding, > > There seems to be no objection. :-) > Would you accept these patches? > Thank you.
All 9 patches applied, thanks. Thierry
pgpRqEdi5grMj.pgp
Description: PGP signature
