On Tue, Dec 13, 2016 at 7:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 13 Dec 2016, Dmitry Vyukov wrote: > >> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote: >> > >> >> >> > If it is >> >> >> > not a bug in kernel source code, then it must not produce a WARNING. >> >> > >> >> > What about a memory allocation failure? The memory management part of >> >> > the kernel produces a WARNING message if an allocation fails and the >> >> > caller did not specify __GFP_NOWARN. >> >> > >> >> > There is no way for a driver to guarantee that a memory allocation >> >> > request will succeed -- failure is always an option. But obviously >> >> > memory allocation failures are not bugs in the kernel. >> >> > >> >> > Are you saying that mm/page_alloc.c:warn_alloc() should produce >> >> > something other than a WARNING? >> >> >> >> >> >> The main thing I am saying is that we absolutely need a way for a >> >> human or a computer program to be able to determine if there is >> >> anything wrong with kernel or not. >> > Doesn't it also produce a WARNING under other circumstances? >> >> No. >> >> OOM is not a WARNING and is easily distinguishable from BUG/WARNING. > >> Memory allocator does not print WARNINGs on allocation failures. > > Do you count dev_warn the same as WARN or WARN_ON? What about dev_WARN > or pr_warn() or printk(KERN_WARNING...)? Maybe we're not talking about > the same messages. > > The USB subsystem has got tons of dev_warn() and dev_err() calls. > Relatively few (if any) of them are for kernel bugs. I grep for "WARNING:". It is not possible to understand what function printed messages on console. Here are my current regexps: https://github.com/google/syzkaller/blob/master/report/report.go#L29 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
