Exception trace for i386
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1053377808.588720@palladium.transmeta.com.suse.lists.linux.kernel
Quoted 4 lines · [email protected] (Linus Torvalds) writes:
Please don't do it this way. For one thing, there are valid uses where you want to enable tracing for just one process. For another, there are actually cases where you may want to trace all page faults, even the ones that don't cause signals - kind of like normal system calls. After
x86-64 has this, (pagefault_trace), but it's usually hidden in a debug CONFIG and not too useful in normal operation (because it generates too much output), so I didn't port this. At one point I also did a sysctl to echo a string into and strcmp the process ->comm against this, but it was a bit ugly so I removed it again.
Quoted 6 lines
all, from a behavioural standpoint, that is what they are: implied system calls.
So I think you want to make it per-process, and expose it as a ptrace thing (imaging seeing all the page faults a process is taking with "strace". Potentially quite useful for performance tuning).
Probably, but that's not the intention of this patch. From my experience page fault tracing is too much for printk because it produces too much information. It needs some specialized logging module that is optimized for high frequency logging like SGI ktrace. It could be surely implemented, but I didn't plan to do this work currently. If you wanted it I would suggest considering kprobes or dprobes instead which allows to define logging macros for such things nicely already.
Quoted 4 lines
I don't think it's ever really valid to expose it as a global option, as some programs use page faults (even the signalling kind) to do their own memory management, and making it a global option just makes it hard to work with such programs.
I especially like it being a global option. It has catched bugs on x86-64 that were never noticed before (e.g. subprocesses silently segfaulting that nobody noticed doing the same on i386). Clearly it's an debugging thing and you definitely want an option to turn it off. But having the global option is useful.
Also programs that break with this are much less frequent than you probably think.
-Andi
Quoted 5 lines · Andi Kleen
I especially like it being a global option. It has catched bugs on x86-64 that were never noticed before (e.g. subprocesses silently segfaulting that nobody noticed doing the same on i386). Clearly it's an debugging thing and you definitely want an option to turn it off. But having the global option is useful.
Would you consider doing the logging only, if the process has no real handler for that? (so it's blocking, ignoring or not caring about this signal)
This will reveal only the bugs and not disturb the applications, which do sth. useful with segfaults.
Regards
Ingo Oeser
Quoted 10 lines · Ingo Oeser
Quoted 5 lines · Andi Kleen
I especially like it being a global option. It has catched bugs on x86-64 that were never noticed before (e.g. subprocesses silently segfaulting that nobody noticed doing the same on i386). Clearly it's an debugging thing and you definitely want an option to turn it off. But having the global option is useful.
Would you consider doing the logging only, if the process has no real handler for that? (so it's blocking, ignoring or not caring about this signal)
Yes, I had this idea too and it's already implemented for x86-64.
-Andi