[lkml]   [2010]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 04/10] x86: mce: fix error handling
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

 \ /
  Last update: 2010-07-31 21:11    [W:0.050 / U:1.880 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site