On Thu, Jul 29, 2010 at 12:10 +0200, walter harms wrote: > > > Andi Kleen schrieb: > > > >> IMO memmory allocation fails are dangerous in kernel mode. As it is > >> probably not exploitable because of boot time, it can destroy some > >> sensitive data like dirty disk caches those are going to be written on > >> disk. > > > > It's true for runtime, but not for normal boot time. > > > > Anyways if it happens on boot time the only thing you can do is panic, > > but someone else > > will likely panic anyways for you. Just ignoring it like your patch > > effectively does > > (because nothing will ever look at the ENOMEMs for an initcall) is wrong > > though > > In this case it's actually better to oops like the original code does. > > > > BTW even with your patch likely later code will crash anyways because it > > doesn't > > expect init code to fail. > > > > NTL it is nice to have a error message. for users it is worse if you crash suddenly > with out warning than having a crash with "OOM" before because it gives you a clue > what is going on. > short: > please think of users that are not kernel developers give them a hint what went wrong. > > to make thinks more easy on boot we could replace kalloc() with kmalloc_or_die(). The thing is that this driver does not call kmalloc() explicitly, it uses function those call functions those call kmalloc() :) If we call BUG_ON() in init code, it would not make big overhead and would make fault exactly when bug was detected, independent from caller checks. Andi, are you fine with it? > When anyone runs out of mem on boottime you can panic() instantly. > > just my to cents, > wh > -- 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
