Re: FInal kprobes rollup patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On Mon, 2007-12-17 at 19:27 -0500, Masami Hiramatsu wrote:
> Masami Hiramatsu wrote:
> >> These are:
> >>
> >> -add stack_addr() macro
> >> -I prefer the table defintion macros in mine as it avoids the need
> to
> >> cast the pointer passed to test_bit, but if you want them
> >> to be u32 as in your patch, I can change it.
> > 
> >  please do so. we'd like to reduce ifdefs as less as possible:-)
> > 
> >> -wrmsr/wrmsrl - use wrmsr() for both
> >> -call is_IF_modifier with p->ainsn.insn in both
> >> -check casting of jprobe_saved_sp, I get some compile warnings
> currently
> >> with pointer comparisons to signed/unsigned types.
> > 
> > Could you also add below?
> > - fix some comments (it clarifies the meanings of the code)
> > - add fix_riprel(). this useful to reduce ifdefs.
> > - expand reenter_kprobe(). I think it treat above two blocks.
> > - reassignment of regs->ip in kprobe_handler can be unified
> >   to "regs->ip = (unsigned long)addr;"
> 
> Oh, I forgot to point out important thing.
> - please make bugfix patches first. I think my bugfix patches
>   need to go upstream before unification. It would cause some
>   crashes.
> 

It's pretty hard to move those bugfixes to the head of the queue.

Attached is an mbox of my unification work.  Maybe you could get your
two bugfixes applied to mainline kprobes_32/64.c, then my series
could go in as a merge later on.  Most of my stuff is in kprobes.c
post-unify so the merge would be trivial later.


Ingo, what do you think?  This rollup replaces all of my kprobes
patches to date.  So you could apply patched 1,2/6 from Masami
into 2.6.24 and let mine come in during 2.6.25 as a merge, which
would avoid the conflicts in kprobes_32|64.c?


Harvey

Attachment: final_kprobes_rollup.mbox.gz
Description: GNU Zip compressed data

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux