On Fri, Jun 02, 2006 at 05:52:32AM -0600, Eric W. Biederman wrote:
> Preben Traerup <[email protected]> writes:
>
> > Since I'm one of the people who very much would like best of both worlds,
> > I do belive Vivek Goyal's concern about the reliability of kdump must be
> > adressed properly.
> >
> > I do belive the crash notifier should at least be a list of its own.
> > Attaching element to the list proves your are kdump aware - in theory
> >
> > However:
> >
> > Conceptually I do not like the princip of implementing crash notifier
> > as a list simply because for all (our) practical usage there will only
> > be one element attached to the list anyway.
> >
> > And as I belive crash notifiers only will be used by a very limited
> > number of users, I suggested in another mail that a simple
> >
> > if (function pointer)
> > call functon
> >
> > approach to be used for this special case to keep things very simple.
>
> I am completely against crash notifiers. The code crash_kexec switches to
> is what is notified and it can do whatever it likes. The premise is
> that the kernel does not work. Therefore we cannot safely notify
> kernel code. We do the very minimal to get out of the kernel,
> and it is my opinion we still do to much.
>
> The crash_kexec entry point is not about taking crash dumps. It is
> about implementing policy when the kernel panics. Generally the
> policy we want is a crash dump but the mechanism is general purpose
> and not limited to that.
Does that mean that we can implement only one policy which crash_kexec()
can execute. In this case clash seems to be that we want multiple policies
to co-exist. Like, a user wants to generate a notification for the
remote node so that remote node takes over and then also take crash dump
to diagnose the source of problem on failing node.
>
> You can put anything you want for crash_kexec to execute.
>
How do I ensure co-existence of multiple policies?
> If the problem is strictly limited to hardware failure and software
> can cope with that then don't panic the kernel and execute an orderly
> transition.
>
> If software cannot cope, and must panic the kernel it clearly cannot
> do something sensible.
That's true. Anything which runs after panic() is running in an unreliable
environment. But I guess everybody understands that and all the code which
runs after panic(), is not guranteed to execute successfuly. Otherwise there
is no point in keeping panic_notifier_list around.
So the concern here is that how do we manage multiple policies which should
execute after a crash/panic?
Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
