Re: [Patch] kexec: remove KMSG_DUMP_KEXEC (was Re: Query about kdump_msghook into crash_kexec())

[KOSAKI Motohiro]

Hi

Sorry for the delay. I had got stuck LinuxCon Japan and piled up plenty
paper works.

>>> I think I can agree your proposal. But could you please explain why do 
>>> you think kmsg _before_ kdump and kmsg _in_ kdump are so different? 
>>> I think it is only C level difference. CPU don't care C function and 
>>> anyway the kernel call kmsg_dump() because invoke second kernel even 
>>> if you proposal applied. 
>>> It is only curious. I'm not against your proposal. 
>>> Thanks. 
> 
> Few reasons.
> 
> - There is no correlation between crash_kexec() and kdump_msg(). What
>   you are creating is equivalent of panic notifiers and calling those
>   notifiers before dump happened. So calling it inside of crash_kexec()
>   does not make much sense from code point of view.

Thank you for the replay. I got you _think_ no makes sense, but I haven't
explain what you talk about the code of "code point of view".
If you read the code, you can understand kdump_msg() and panic_notifiers
are not same point.


> - Why does somebody need to keep track of event KMSG_DUMP_KEXEC?

I believe I answered already at last thread.

http://groups.google.com/group/linux.kernel/browse_thread/thread/1084f406573d76ac/daa1a08804385089?q=kexec%3A+remove+KMSG_DUMP_KEXEC&lnk=ol&;


> - There is one kernel CONFIG option introduce which looks completely
>   superfluous.

What you mean "superfluous"? We already have billion kernel CONFIG.
Is it also bad?

> My general take on the whole issue.
> 
> - In general I think exporting a hook to module so that they can do
>   anything before crash is a bad idea. Now this can be overloaded to
>   do things like sending crash notifications in clustered environement
>   where we recommend doing it in second kernel.

??
It's not my issue and I haven't talked about such thing. I guess you
confuse I and Aguch-san or someone else.

> 
> - Even if we really have to do it, there seemed to be two concern
>   areas.
> 
> 	- Reliability of kdump_msg() generic infrastructure and its
>   	  capability in terms of handling races with other cpus and
> 	  NMIs.
> 
> 	- Reliability of module which is getting the callback from
> 	  kdump_msg().

Indeed. I thought Aguch-san said he promised he work on improve them.
However it doesn't happen yet. Okay, I


>  I think in one of the mails I was discussing that common infrastructure
>  between kdump and kmsg_dump() can be put in a separate function, like
>  stopping all cpus etc to avoid races in generic infrastrucutre and
>  then first we can all kmsg_dump() and then crash_kexec().

Nice idea! Yes. I didn't think enterprise folks start to use this feature
and it now happen.
If nobody are working on this, I'll do it.


>  But this still does not provide us any protection against modules getting
>  control after crash and possiblly worsen the situation.

I think this doesn't big matter. If module author hope to get hook, they
can use kprobe in nowadays. I don't think we can make perfect kprobe protection.
I think I wrote this at last thread too.

Probably most reliability stupid module detect way is, watching lkml and revewing
kmsg_dump() user conteniously. However, if you strongly worry about this issue,
I can agree we make tiny foolish module protection. (but I don't have concrete
idea yet)



--
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/