On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote: > The real problem is that the kernel development community doesn't have > a fixed policy on how to handle memory allocation errors. There are > several possibilities: > > Ignore them on the grounds that they will never happen. > (Really? And what is the size limit above which they > might happen?) > It's pretty rare to ignore allocation failures these days. It causes static checker warnings. Sometimes it's accepted for people to ignore errors during boot but I hate that because how am I supposed to filter out those static checker warnings? It's better to pretend that the kernel will still boot without essential hardware instead of wasting everyone's time who looks at checker output. > Ignore them on the grounds that the machine will hang or > crash in the near future. (Is this guaranteed?) On boot sometimes yes. > > Treat them like other errors: try to press forward (perhaps > in a degraded mode). > > Treat them like other errors: log an error message and try > to press forward. > The standard is to treat them like errors and try press forward in a degraded mode but don't print a message. Checkpatch.pl complains if you print a warning for allocation failures. A lot of low level functions handle their own messages pretty well but especially kmalloc() does. I also have a special static checker warning for when people do: foo = alloc(); BUG_ON(!foo); People do that occasionally but fortunately it's pretty rare. 10 years ago that's how btrfs did error handling, but now there are only 4 of these still remaining in btrfs. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
