lkml.org 
[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] Merkey's Kernel Debugger
    On Fri, Aug 08, 2008 at 09:50:00AM -0500, Cliff Wickman wrote:
    > On Fri, Aug 08, 2008 at 09:29:53AM -0400, Vivek Goyal wrote:
    > > On Fri, Aug 08, 2008 at 04:29:16AM +0200, Andi Kleen wrote:
    > > > > panic() is the only place where kdump gets a chance to run first and
    > > > > panic notifiers are not executed.
    > > >
    > > > To be fully clear panic() that is called outside oops/exception context
    > > >
    > > > s/panic/die notifiers/
    > > >
    > > > >
    > > > > To me so far only in kernel debugger seems to be a reasonable candiate
    > > >
    > > > Yes a kernel debugger should be able to hook into panic()
    > > >
    > > > In fact it can do that already by just setting a break point,
    > > > but clearly having a real notifier is preferable.
    > > >
    > > > The use case would be then that the kernel debugger would
    > > > have some command to trigger a dump.
    > > >
    > > > > which needs to run before kdump after a panic event. If a debugger
    > > > > is really getting merged into the kernel, then I think debugger can
    > > >
    > > > kgdb is already merged. Also the x86 notifiers are general
    > > > enough that there are a couple of debuggers floating around
    > > > that are just using existing interfaces (as in need very little in terms
    > > > of core patching)
    > > >
    > > > > put a hook in the panic() before kdump. Wouldn't this solve the problem?
    > > >
    > > > Yes it would, but right now there is no such hook. Also if there
    > > > was such a hook kdump could use it like everyone else.
    > > >
    > > > There's a priority scheme in notifiers so you can still run usually last.
    > >
    > > Hi Andi,
    > >
    > > IIUC, there are two lists for exception and panic notifications. All the
    > > exceptios, NMI related notifications go through "die_chain" and
    > > all the panic notifications are done through "panic_notifier_list".
    > >
    > > Are you suggesting that kdump should be put onto panic_notifier_list, in
    > > such a way so that it runs last?
    > >
    > > Just few points to ponder.
    > >
    > > - panic_notifier_list is exported and any module can register and make use
    > > of it. As you mentioned in your other mail, there are lot of drivers out
    > > there with crappy code and if we do it, all the drivers get a chance
    > > to do stuff after panic() and there is no gurantee that kdump code will
    > > ever get a chance to run.
    > >
    > > - Kdump is built on the philosophy that after a panic(), one should do as
    > > as little as possible in the kernel and all the actions should be
    > > deferred to new kernel. That's why we recommend that all the panic
    > > notifier actions (except debugger), should be done in second kernel. It
    > > does introduce a little delay in notification but it also makes it more
    > > reliable.
    > >
    > > - Neil Horman, has already provided infrastructure so that one can put
    > > it user space code in second kernel's initrd and it will be executed.
    > > This can be easily done for modules also.
    > >
    > > But somehow nobody seems to be interested in doing things in second kernel
    > > and everybody wants to run its post panic code in the first kernel. So
    > > far, except debugger, we have not run into any strong case which needs to
    > > run post panic code in first kernel and things will not work out if post
    > > panic actions are taken in second kernel.
    >
    > In the case of the cross-partition driver, running panic notification in the
    > second kernel is an interesting idea.
    >
    > I discussed it with Robin Holt, who is more knowledgable than I on the
    > details of that driver, and he told me that there is a great deal of
    > state information needed for the notification. It's easy to do in the
    > first kernel, but extremely difficult in a second kernel.
    >

    Generally what kind of state information has to be passed?

    > Couldn't we have some tunable flexability in that area, to determine
    > should run on a panic, and in what order?

    May be that's the way forward. Export the list of registered handlers on
    panic_notifier_list through sysfs or debugfs and also provide flexibility
    that user can change the priorities from userspace. That should work
    for all.

    Thanks
    Vivek


    \
     
     \ /
      Last update: 2008-08-11 15:01    [W:0.026 / U:90.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site