From: masami.hiramatsu.pt@hitachi.com (Masami Hiramatsu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v14 7/7] ARM: kprobes: enable OPTPROBES for ARM 32
Date: Tue, 09 Dec 2014 19:14:55 +0900 [thread overview]
Message-ID: <5486CB9F.6030804@hitachi.com> (raw)
In-Reply-To: <1418039451.3647.48.camel@linaro.org>
(2014/12/08 20:50), Jon Medhurst (Tixy) wrote:> arch_optimize_kprobes is calling __arch_optimize_kprobes, which is
> iterating over a list of probes and removing each one in turn, if this
> is happening on multiple cpu's simultaneously, it's not clear to me that
> such an operation is safe. list_del_init calls __list_del which does
>
> next->prev = prev;
> prev->next = next;
>
> so what happens if another cpu is at the same time updating any of those
> list entries? Without even fully analysing the code I can see that with
> the fact that the list handling helpers have no memory barriers, that
> the above two lines could be seen to execute in the reverse order, e.g.
>
> prev->next = next;
> next->prev = prev;
>
> so another CPU could find and delete next before this one has finished
> doing so. Would the list end up in a consistent state where no loops
> develop and no probes are missed? I don't know the answer and a full
> analysis would be complicated, but my gut feeling is that if a cpu can
> observe the links in the list in an inconsistent state then only bad
> things can result.
Just a comment, arch_optimize_kprobes() are only called under
kprobe_mutex held. No concurrent update happens :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt at hitachi.com
next prev parent reply other threads:[~2014-12-09 10:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 6:27 [PATCH v14 0/7] ARM: kprobes: OPTPROBES and other improvements Wang Nan
2014-12-08 6:27 ` [PATCH v14 1/7] ARM: probes: move all probe code to dedicate directory Wang Nan
2014-12-08 6:27 ` [PATCH v14 2/7] ARM: kprobes: introduces checker Wang Nan
2014-12-08 6:28 ` [PATCH v14 3/7] ARM: kprobes: collects stack consumption for store instructions Wang Nan
2014-12-08 6:28 ` [PATCH v14 4/7] ARM: kprobes: disallow probing stack consuming instructions Wang Nan
2014-12-08 6:28 ` [PATCH v14 5/7] ARM: kprobes: Add test cases for " Wang Nan
2014-12-08 6:28 ` [PATCH v14 6/7] kprobes: Pass the original kprobe for preparing optimized kprobe Wang Nan
2014-12-08 6:28 ` [PATCH v14 7/7] ARM: kprobes: enable OPTPROBES for ARM 32 Wang Nan
2014-12-08 11:04 ` Jon Medhurst (Tixy)
2014-12-08 11:15 ` Wang Nan
2014-12-08 11:50 ` Jon Medhurst (Tixy)
2014-12-08 12:06 ` Wang Nan
2014-12-08 12:31 ` Wang Nan
2014-12-08 13:22 ` Jon Medhurst (Tixy)
2014-12-08 13:48 ` Wang Nan
2014-12-09 10:14 ` Masami Hiramatsu [this message]
2014-12-09 10:30 ` Jon Medhurst (Tixy)
2014-12-09 15:13 ` 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=5486CB9F.6030804@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 NNTP newsgroup(s).