On 03/29/2017 01:25 AM, Masami Hiramatsu wrote:
> On Wed, 29 Mar 2017 08:30:05 +0200
> Ingo Molnar wrote:
>>
>> * Masami Hiramatsu wrote:
>>
>>> @@ -1824,6 +1823,30 @@ void unregister_jprobes(struct jprobe **jps, int num)
>>> EXPORT_SYMBOL_GPL(unregister_jprobes);
>>>
>>> #ifdef CONFIG_KRETPR
On 12/02/2016 03:27 PM, Kees Cook wrote:
>> + /* If there's already an active tracing relationship, then make an
>
> I'll adjust the comment style here and add it to my tree for -next.
Thanks!
I guess the tweak is that it should have an empty "/*" line?
FWIW, checkpatch.pl doesn't warn ab
ame thread group as the current ptrace parent.
Signed-off-by: Josh Stone
Cc: Kees Cook
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/yama/yama_lsm.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/secu
ell?
> --
>
> From: Russell King
>
> commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.
>
> Josh Stone reports:
>
> I've discovered a case where both arm and arm64 will miss a ptrace
> syscall-exit that they should report. If the syscall is entered
> witho
On 05/21/2015 10:04 AM, Joe Perches wrote:
> On Thu, 2015-05-21 at 11:44 -0500, Bjorn Helgaas wrote:
>> My git-fu isn't awesome
>
> Yeah, mine either.
>
>> (git log --oneline --abbrev-commit --abbrev=10
>> | cut -f1 -d" " | grep ...), but I *think* we have three git
>> SHA-1s so far that
On 11/24/2014 01:46 PM, Michal Marek wrote:
> Dne 21.11.2014 v 19:40 Josh Stone napsal(a):
>> Due to recent codegen issues, gcc -fvar-tracking-assignments was
>> unconditionally disabled in commit 2062afb4f804a ("Fix gcc-4.9.0
>> miscompilation of load_balance() in s
now build v3.18-rc5 with Fedora's i686 and
x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.
Cc: Frank Ch. Eigler
Cc: Jakub Jelinek
Cc: Josh Boyer
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Markus Trippelsdorf
Cc: Michel Dänzer
Signed-off
On 11/05/2014 01:05 AM, Masami Hiramatsu wrote:
> [Off topic] I really don't like that the current SDT's semaphore. If the user
> apps
> see the instruction at the probe point, it is easy to check whether the event
> is
> enabled or not. Thus I recommend to change its implementation and update
>
I can now build 3.17 with Fedora's i686 and
x86_64 configs, and this is completely clean with GCC_COMPARE_DEBUG.
Cc: Frank Ch. Eigler
Cc: Greg Kroah-Hartman
Cc: Jakub Jelinek
Cc: Josh Boyer
Cc: Linus Torvalds
Cc: Markus Trippelsdorf
Cc: Michel Dänzer
Signed-off-by: Josh Stone
---
Ma
on of dyninst (PR14702)
+ not all registers are made available on 32-bit x86 (PR15136)
See dyninst/README and the systemtap/dyninst Bugzilla component
(http://tinyurl.com/stapdyn-PR-list) if you want all the gory
details about the state of the feature.
= Contributors for this release
A
On 12/12/2013 06:03 AM, Ingo Molnar wrote:
>> No, because the int3 already changes the original instruction.
>> This means that you cannot skip singlestep(or emulate) the
>> instruction which is copied to execution buffer (ainsn->insn),
>> even if you have such the flag.
>> So, kprobe requires the
On 11/20/2013 09:56 AM, Steven Rostedt wrote:
> On Wed, 20 Nov 2013 12:36:00 -0500
> "Frank Ch. Eigler" wrote:
>
>> Hi -
>>
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
>>>
>>> That's generally th
On 04/03/2013 07:44 AM, Frank Ch. Eigler wrote:
> Hi -
>
> On Wed, Apr 03, 2013 at 02:49:53PM +0200, Frederic Weisbecker wrote:
>
>> Sounds good, would you like to propose a version? We are also
>> interested in a timer tick event tracepoint for dynticks debugging.
>
> How about this?
>
> Autho
On 03/22/2013 08:10 AM, Oleg Nesterov wrote:
> This looks simple, but probably we need to add the additional "ulong bp_vaddr"
> argument for rp_handler().
FWIW, in SystemTap we don't currently do anything that would need
bp_vaddr. The uprobe_consumer already gives the context, so I'm not
sure wha
On 01/24/2013 07:40 AM, Oleg Nesterov wrote:
> I'll try to implement the pid-base filtering at least for
> tracing/uprobe_events, but this needs a time. Not only I am not familiar
> with this code, I am not sure how this interface should actually look.
> And I agree, perf should be able to use it s
On 01/12/2013 09:06 AM, Oleg Nesterov wrote:
> On 01/10, Josh Stone wrote:
>> and for uretprobes we want the original return address.
>
> Yes, Anton's v2 does this.
>
> But. Don't you also need to know the address of function we are going
> to ret
Hi Christoph,
On 01/11/2013 01:32 AM, Christoph Hellwig wrote:
> On Thu, Jan 10, 2013 at 03:01:46PM -0800, Josh Stone wrote:
>> The original pull message for uprobes (commit 654443e2) noted:
>>
>> This tree includes uprobes support in 'perf probe' - but SystemTap
eeds to be exported. This patch first adds the obvious
exports for uprobe_register and uprobe_unregister. Then it also adds
one for task_user_regset_view, which is necessary to get the correct
state of userspace registers.
Signed-off-by: Josh Stone
---
kernel/events/uprobes.c | 3 +++
kerne
On 01/08/2013 06:27 AM, Anton Arapov wrote:
> On Sun, Dec 23, 2012 at 04:49:10PM +0100, Oleg Nesterov wrote:
>> On 12/22, Oleg Nesterov wrote:
Just change regs->ip before calling ->handler().
>>>
>>> Josh, Frank, will it work for you?
>>
>> Wait, probably I was confused by this patch and 4/6..
On 11/06/2012 09:02 AM, Oleg Nesterov wrote:
> On 11/06, Srikar Dronamraju wrote:
>> Another reason for having the filters in the current way was to have a
>> set of standard filters in uprobes code so that all users dont need to
>> recreate these filters.
>
> IOW, you mean that both register_for_
strumented by the current version of dyninst
See dyninst/README and the systemtap/dyninst Bugzilla component
(http://tinyurl.com/stapdyn-PR-list) if you want all the gory
details about the state of the feature.
= Contributors for this release
Alexander Lochmann*, Bryn M. Reeves, Chri
21 matches
Mail list logo
