From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Satoshi Oshima <soshima@redhat.com>
Cc: karim@opersys.com, Richard J Moore <richardj_moore@uk.ibm.com>,
systemtap@sources.redhat.com, Andi Kleen <ak@suse.de>,
Masami Hiramatsu <hiramatu@sdl.hitachi.co.jp>,
Masami Hiramatsu <masami.hiramatsu@gmail.com>,
michel.dagenais@polymtl.ca, Roland McGrath <roland@redhat.com>,
sugita@sdl.hitachi.co.jp
Subject: Re: Hitachi djprobe mechanism
Date: Thu, 04 Aug 2005 03:31:00 -0000 [thread overview]
Message-ID: <20050804032931.GA20153@Krystal> (raw)
In-Reply-To: <20050804011246.GB17537@Krystal>
Points about interrupts are answered by your later posts. Thanks.
* Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> * Satoshi Oshima (soshima@redhat.com) wrote:
> > I see.
> >
> > We should add another limitation to djprobe limitation list.
> > Current list is ...
> > ------------------------------------------
> >
> > limitation of djprobe
> >
> > djprobe user must avoid inserting a probe into the place below:
> >
> > code includes relative jmp instruction
> > code includes call instruction
> > code includes int instruction
>
> Well... When you say "code includes int instruction", this is really not what I
> mean by "code being interrupted".
>
> Interruption are asynchronous to the executing code, they may happen anywhere
> where interrupts are not disabled. You still can have a int instruction which
> synchronously raises an interrupt, and yes, it's not safe to overwrite them. But
> the prior problem is asynchronous interruptions.
>
>
>
> > functions that preempt current process such as sched() or might_resched()
> >
>
> Well, if you run a voulountarily preemptble kernel, those will be explicit
> calls. On the other hand, running a full preemptible kernel will make scheduler
> being called from anywhere in your code (using an asynchronous interrupt).
> Everywhere where interrupts are not disabled or preemption is not disabled are
> at risk.
>
> > >The only way you could limit that is if you did a static analysis
> > >and forbade any insertion of probes on any instruction preceeding
> > >a call that _may_ result in a process scheduling ... Surely you see
> > >this can't scale.
> >
> > I don't see why that analysis is required.
> > We can simply suggest that user should avoid a call
> > instruction.
> >
> > The problem is EIPs which is included with replacing
> > code on stack. So there is no problem when they don't
> > try to replace call instruction.
> >
>
> Asynchronous interrupts will return to any instruction which is not in a zone
> where interrupts are disabled. No need of call instruction to have this problem.
> Well, in fact, even worst : non maskable interrupts can return _anywhere_,
> excepted in the fault handler code (a double fault is handled by a abort if I
> remember well).
>
> >
> > >>In addition, all CPU run on bypass code after int3 bypass
> > >>is created. (In another word, once int3 bypass would be set,
> > >>all CPU never push replacing instruction address on it's stack)
> > >>
> > >>So we need to take care of EIPs on current process of all CPUs
> > >>and interrupt stack. Now we are implementing this check code,
> > >>and we will provide soon.
> > >
> > >But you have no way to figure out whether what you've found on the
> > >stack is an address to some piece of code or just some valid data ...
> >
> > We are implementing two different way to check this.
> >
> > First one:
> > Each interrupt handler push EIP on the stack to djprobe's
> > per cpu data structure before calling do_irq or something,
> > and pop EIP after returning.For checking safety,
> > djprobe look through this pushed EIPs.
> >
> > djprobe can easily check EIPs which are included on stacks.
> >
> > But we are afraid that upstream would not accept this
> > approach. So we are now trying another one.
> >
>
> Well, it will clearly have a performance cost on live systems I am not sure many
> people will like.
>
> >
> > Second one:
> > Simply looking through current stack and interruption stack.
> > djprobe may find the data that is same to an address to replace.
> > When it would happen, djprobe can easily postpone to replace
> > and wait for next check.
> >
> > This implementation brings some delay to replace int 3 with
> > jmp. But probe code is still valid by kprobe and there is
> > no other side effect. Probe cost is same as kprobe.
> >
>
> How do you plan to check all processors'stack ?
>
> > Currently we have no plan to limit djprobe not to use for
> > less than 5 bytes instruction. But when we would move to it,
> > djprobe will not provide any check on stack. There is no
> > problem when a stack has the same addresses to replace
> > if the candidate is more than 4 byte. Because a processor
> > can run jmp instruction instead of replaced code or int 3
> > instruction.
> >
>
> Instruction cache coherency might be a problem there, even if the instruction to
> replace is bigger than 5 bytes. You have to make sure the instruction cache of
> each CPU is flushed before they go back to this modified section.
>
> Mathieu
>
>
>
> OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
> Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
>
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2005-08-04 3:31 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 21:05 Keshavamurthy, Anil S
2005-07-28 1:51 ` Karim Yaghmour
2005-07-28 2:10 ` Karim Yaghmour
2005-07-28 16:23 ` Masami Hiramatsu
2005-07-28 16:28 ` Karim Yaghmour
2005-07-28 17:36 ` Mathieu Desnoyers
[not found] ` <20050728110717.A30199@unix-os.sc.intel.com>
2005-07-28 18:33 ` Mathieu Desnoyers
[not found] ` <20050728133456.A32210@unix-os.sc.intel.com>
2005-07-28 23:53 ` Richard J Moore
2005-07-29 5:59 ` Mathieu Desnoyers
2005-07-29 7:55 ` Andi Kleen
2005-07-29 8:44 ` Richard J Moore
2005-07-29 8:46 ` Andi Kleen
2005-07-29 15:51 ` Mathieu Desnoyers
2005-07-30 15:55 ` Andi Kleen
2005-07-30 16:54 ` Mathieu Desnoyers
2005-07-31 22:03 ` Andi Kleen
2005-07-31 23:11 ` Mathieu Desnoyers
2005-08-01 15:37 ` Andi Kleen
2005-08-01 8:44 ` Richard J Moore
2005-08-01 13:21 ` Mathieu Desnoyers
2005-08-01 19:57 ` Satoshi Oshima
2005-08-01 20:21 ` Karim Yaghmour
2005-08-01 22:12 ` Satoshi Oshima
2005-08-01 22:54 ` Karim Yaghmour
2005-08-02 18:42 ` Satoshi Oshima
2005-08-03 14:50 ` Karim Yaghmour
2005-08-04 1:19 ` Mathieu Desnoyers
2005-08-04 3:31 ` Mathieu Desnoyers [this message]
2005-08-02 9:42 ` Mathieu Lacage
2005-08-02 15:09 ` Karim Yaghmour
2005-10-07 15:35 ` Richard J Moore
2005-10-08 18:33 ` mathieu lacage
2005-10-08 21:59 ` Richard J Moore
2005-10-08 23:24 ` Roland McGrath
2005-10-22 11:49 ` mathieu lacage
2005-10-22 22:09 ` Roland McGrath
2005-10-24 6:33 ` Mathieu Lacage
2005-10-24 19:48 ` Roland McGrath
[not found] ` <43621B0D.70204@sophia.inria.fr>
2005-11-07 10:04 ` mathieu lacage
2005-11-07 10:06 ` mathieu lacage
2005-11-08 9:49 ` Richard J Moore
2005-10-09 16:47 ` mathieu lacage
2005-08-02 15:33 ` Mathieu Lacage
2005-08-02 15:36 ` Mathieu Lacage
2005-08-02 16:12 ` Karim Yaghmour
2005-08-02 16:30 ` Mathieu Lacage
2005-08-02 16:46 ` Karim Yaghmour
2005-08-04 17:09 ` Mathieu Lacage
2005-08-03 14:46 ` Andi Kleen
2005-07-29 16:06 ` Frank Ch. Eigler
2005-07-29 18:24 ` sugita
2005-07-28 18:13 ` Richard J Moore
-- strict thread matches above, loose matches on Subject: below --
2005-08-01 22:49 Keshavamurthy, Anil S
2005-08-01 23:05 ` Karim Yaghmour
2005-08-01 23:18 ` Karim Yaghmour
2005-08-01 22:41 Keshavamurthy, Anil S
2005-08-02 3:21 ` Roland McGrath
2005-08-02 3:35 ` Karim Yaghmour
2005-08-01 20:46 Keshavamurthy, Anil S
2005-08-01 21:08 ` Karim Yaghmour
2005-08-01 16:14 Keshavamurthy, Anil S
2005-08-01 20:31 ` Roland McGrath
2005-08-04 0:28 ` Mathieu Desnoyers
2005-08-04 10:01 ` Andi Kleen
2005-08-05 16:25 ` Mathieu Desnoyers
2005-08-05 16:39 ` Andi Kleen
2005-08-01 15:50 Keshavamurthy, Anil S
2005-08-01 16:03 ` Mathieu Desnoyers
2005-07-29 0:18 Keshavamurthy, Anil S
2005-07-29 1:48 ` Karim Yaghmour
2005-07-29 3:41 ` Mathieu Desnoyers
2005-07-29 3:47 ` Karim Yaghmour
2005-07-29 1:53 ` Frank Ch. Eigler
2005-08-01 9:02 ` Mathieu Lacage
2005-08-01 13:18 ` Mathieu Desnoyers
2005-08-02 7:07 ` Mathieu Lacage
2005-07-22 18:09 Frank Ch. Eigler
2005-07-21 22:32 Richard J Moore
2005-07-21 22:52 ` Roland McGrath
2005-07-22 2:52 ` Richard J Moore
2005-07-26 7:14 ` Masami Hiramatsu
2005-07-26 7:53 ` Roland McGrath
2005-07-27 13:02 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050804032931.GA20153@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=ak@suse.de \
--cc=hiramatu@sdl.hitachi.co.jp \
--cc=karim@opersys.com \
--cc=masami.hiramatsu@gmail.com \
--cc=michel.dagenais@polymtl.ca \
--cc=richardj_moore@uk.ibm.com \
--cc=roland@redhat.com \
--cc=soshima@redhat.com \
--cc=sugita@sdl.hitachi.co.jp \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).