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. Alan Stern -- 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
