Messages in this thread | | | Date | Tue, 13 Dec 2016 13:38:26 -0500 (EST) | From | Alan Stern <> | Subject | Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns |
| |
On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern <stern@rowland.harvard.edu> 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
| |