Re: [PATCH v1 1/6] Add oops notification chain.

[Aaron Durbin]

On Tue, Jan 25, 2011 at 1:54 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> On 01/25/2011 04:43 PM, Aaron Durbin wrote:
>>
>> On Tue, Jan 25, 2011 at 1:36 PM, Jeff Garzik<jeff@xxxxxxxxxx>  wrote:
>>>
>>> On 01/25/2011 03:01 PM, Mike Waychison wrote:
>>>>
>>>> On Mon, Jan 24, 2011 at 6:06 PM, Greg KH<greg@xxxxxxxxx>    wrote:
>>>>>
>>>>> On Mon, Jan 24, 2011 at 04:24:39PM -0800, Mike Waychison wrote:
>>>>>>
>>>>>> From: Aaron Durbin<adurbin@xxxxxxxxxx>
>>>>>>
>>>>>> Later firmware patches in this series would like to be able to be
>>>>>> notified whenever an oops occurs on the system, so that it can be
>>>>>> recorded in the boot log.
>>>>>>
>>>>>> This patch introduces a notifier_block called "oops_notifier_list"
>>>>>> so that drivers can register to get called whenever an Oops is
>>>>>> triggered.
>>>>>
>>>>> But we already have a panic notifier list.  Why create a new one?
>>>>> What's wrong with the existing one that doesn't work properly for you?
>>>>
>>>> AFAICT, the panic notifier list doesn't get called on oops.
>>>
>>> Have you tried playing with panic_on_oops ?
>>
>> Yes. We actually run in that setup. However, oops != panic. They are 2
>> distinct events. Sometimes we panic without the oops under certain
>> situations. That is why it is desirable to have 2 distinct events.
>
> That's a circular statement:  They are distinct events, so it is desirable
> that they be distinct events?

I'm sorry. I should have described which events I was talking about.
They are 2 distinct events in the kernel, and we would look like them
that way in our non-volatile event log as well. As you are very much
aware panic() can be called from outside of the oops path; seeing a
panic doesn't imply an oops (likewise if panic on oops isn't set).

>
> Set a flag, a la oops_in_progress (unfortunately name, as it's called during
> a panic too).  Call it...  oops_really_in_progress.  Then will the panic
> notifier list suffice?

It would only appear to work as long as panic on oops isn't set. As I
mentioned in the previous email we do run with that on, but I think it
is desirable to keep the 2 paths distinct -- thus the separate
notifier chain.

That being said, we could probably add code to distinguish the
difference between the 4 states of oops_in_progress and
oops_really_in_progress and call the panic notifier list at
oops_enter(). I'm not sure why that would be more desirable than an
explicit notification mechanism for oops though.

As Mike talked about it might be more desirable to actually pass a
reason field that indicates the appropriate kernel event. However, the
naming of some of the variables becomes less clear. Maybe name it
panic_oops_notifier_list? That way there would only be a single
notifier chain.

-Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/