[RFC PATCH 1/2] check safety in workqueue
Masami Hiramatsu
hiramatu@sdl.hitachi.co.jp
Fri Aug 19 14:19:00 GMT 2005
Hi, Andi
Andi Kleen wrote:
> [cc list from hell trimmed]
>
> (Didn't do an in depth review. Just some things that jumped out on me)
Thank you.
>>+# jmp into this function from other functions.
>>+.global arch_tmpl_stub_entry
>>+arch_tmpl_stub_entry:
>>+ nop
>>+ subl $8, %esp #skip segment registers.
>>+ pushf
>>+ subl $20, %esp #skip segment registers.
>
>
> I don't know why you try to fake pt_regs. Seems useless.
I think we needs this pt_regs to access registers from the C program
called by the djprobe.
>>+static void local_flush_icache(void * info)
>>+{
>>+ cpuid_eax(0);
>
>
> cpuid_eax is not marked volatile, so gcc will likely optimize this away.
You are right.
> x86-64 has a sync_core() that works. But I'm not convinced it even makes
> any sense to have.
In my opinion, to port sync_core() function into i386/processor.h is
better than it.
>>+#define ARCH_STUB_VAL_IDX ((long)&arch_tmpl_stub_val - (long)&arch_tmpl_stub_entry + 1)
>>+#define ARCH_STUB_CALL_IDX ((long)&arch_tmpl_stub_call - (long)&arch_tmpl_stub_entry + 1)
>>+#define ARCH_STUB_INST_IDX ((long)&arch_tmpl_stub_inst - (long)&arch_tmpl_stub_entry)
>>+#define ARCH_STUB_END_IDX ((long)&arch_tmpl_stub_end - (long)&arch_tmpl_stub_entry)
>>+#define ARCH_STUB_SIZE ((long)&arch_tmpl_stub_end - (long)&arch_tmpl_stub_entry + 5)
>
>
> You likely need RELOC_HIDEs here, otherwise the gcc optimizer might
> do unexpected things again.
I mistook declaring of the types of symbols. I should declare symbols
like below. The size of kprobes_opecode_t is 1 byte.
extern kprobe_opcode_t arch_tmpl_stub_entry;
extern kprobe_opcode_t arch_tmpl_stub_val;
extern kprobe_opcode_t arch_tmpl_stub_call;
extern kprobe_opcode_t arch_tmpl_stub_inst;
extern kprobe_opcode_t arch_tmpl_stub_end;
So, I think we do not need RELOC_HIDEs any more.
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp
More information about the Systemtap
mailing list