Bug#604453: Fwd: Fix the uprobes.ko path when used with remotes
Hi David and Frank, David Smith writes: > The whitelist test is pretty old, and should probably be removed. The > stuff in scripts/kprobes_test is much closer to what I think you want, > but of course it doesn't use systemtap, it tests "raw" kprobes. It > probably wouldn't be that difficult to modify > scripts/kprobes_test/gen_code.py to produce a systemtap module instead > of a "raw" kprobes module. thanks for the pointer. I forked gen_code_all.sh to a version that incrementally adds new probes to the set until the kernel crashes. The log looks like: round 1: adding run_init_process to the set round 2: adding _stext to the set round 3: adding hypercall_page to the set round 4: adding arch_local_save_flags to the set round 5: adding arch_local_irq_disable to the set round 6: adding arch_local_irq_enable to the set round 7: adding run_init_process to the set round 1: adding _stext to the set round 2: adding hypercall_page to the set round 3: adding arch_local_save_flags to the set round 4: adding arch_local_irq_disable to the set round 5: adding arch_local_irq_enable to the set round 6: adding run_init_process to the set round 7: adding init_post to the set round 8: adding do_one_initcall to the set round 9: adding match_dev_by_uuid to the set round 10: adding name_to_dev_t to the set round 11: adding arch_local_irq_restore to the set round 12: adding arch_local_irq_disable to the set round 13: adding native_read_cr4 to the set round 14: adding native_read_cr4_safe to the set round 15: adding native_wbinvd to the set round 16: adding native_read_msr_safe to the set round 17: adding native_read_pmc to the set round 18: adding cpuid to the set round 19: adding pte_pfn to the set round 20: adding pfn_pte to the set round 21: adding native_store_gdt to the set round 22: adding native_store_idt to the set round 23: adding xen_mc_batch to the set round 24: adding clamp_max_cpus to the set round 25: adding xen_cpuid to the set round 26: adding xen_set_debugreg to the set After that I get [440390.108932] Unrecoverable kprobe detected at 8100311e. [440390.108936] Dumping kprobe: [440390.108939] Name: xen_set_debugreg [440390.108940] Address: 8100311e [440390.108940] Offset: 0 [440390.108949] [ cut here ] [440390.108952] kernel BUG at /tmp/buildd/linux-2.6-3.0.0/debian/build/source_amd64_none/arch/x86/kernel/kprobes.c:523! and the machine is dead. Can we please blacklist these in Linux or systemtap? -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604453: Fwd: Fix the uprobes.ko path when used with remotes
On 08/12/2011 06:27 AM, Frank Ch. Eigler wrote:
> David, can you advise to what extent the results of this whitelist
> test could be useful, for example to populate our blacklist? The
> number of non-inlined kernel functions is far greater than 963, so
> perhaps this default test run just looked at those functions listed by
> the various tapsets. If so, one'd need to add gross patterns like
> kernel.function("*").call to give the kernel a manlier workout.
The whitelist test is pretty old, and should probably be removed. The
stuff in scripts/kprobes_test is much closer to what I think you want,
but of course it doesn't use systemtap, it tests "raw" kprobes. It
probably wouldn't be that difficult to modify
scripts/kprobes_test/gen_code.py to produce a systemtap module instead
of a "raw" kprobes module.
--
David Smith
dsm...@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#604453: Fwd: Fix the uprobes.ko path when used with remotes
Hi -
On Fri, Aug 12, 2011 at 02:14:01PM +0300, Timo Juhani Lindfors wrote:
> > alibi procedure, see https://bugzilla.redhat.com/show_bug.cgi?id=655904
>
> Thanks. I can confirm that these instructions crash
> linux-image-3.0.0-1-amd64 3.0.0-1
>
> at least under xen.
OK. So that confirms kernel bugs. Perhaps you should fork this bug
against the kernel, and hope for the best.
> The README in the same directory talks about
> generating a whitelist of safe probe points. [...]
> After this I get the following output:
> [...]
> $ sudo runtest whitelist.exp
> Running ./systemtap.stress/whitelist.exp ...
> Start a fresh stp_genwhitelist test.
> current_size_const is initialized as 107
> Current size of probes.pending is 963
> Start a probe test...
> [...]
> Completed one probe test.
> Current size of probes.pending is 0
> Running level increased to 3
> Exceed max running level limit.
> Remove all temporary files, unregister the service and return.
David, can you advise to what extent the results of this whitelist
test could be useful, for example to populate our blacklist? The
number of non-inlined kernel functions is far greater than 963, so
perhaps this default test run just looked at those functions listed by
the various tapsets. If so, one'd need to add gross patterns like
kernel.function("*").call to give the kernel a manlier workout.
- FChE
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
