This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.6-594-g12aa5f9
- From: Mark Wielaard <mjw at redhat dot com>
- To: systemtap at sourceware dot org
- Cc: Frank Eigler <fche at redhat dot com>
- Date: Wed, 14 Dec 2011 10:42:44 +0100
- Subject: Re: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.6-594-g12aa5f9
- References: <20111213223224.10508.qmail@sourceware.org>
On Tue, 2011-12-13 at 22:32 +0000, fche@sourceware.org wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "systemtap: system-wide probe/trace tool".
>
> commit 12aa5f9c1d9ac3dc7003f9c0e0b8e34c23d67407
> Author: Frank Ch. Eigler <fche@redhat.com>
> Date: Tue Dec 13 17:27:38 2011 -0500
>
> PR13489/PR11671: more lockdep antihistamines
>
> * runtime/task_finder_vma.c (__stp_tf_vma_new_entry): Use
> STP_ALLOC_FLAGS for new vma entry memory allocation needs.
>
> diff --git a/runtime/task_finder_vma.c b/runtime/task_finder_vma.c
> index 90a34ba..093d307 100644
> --- a/runtime/task_finder_vma.c
> +++ b/runtime/task_finder_vma.c
> @@ -44,6 +44,8 @@ static struct hlist_head *__stp_tf_vma_map;
>
> // __stp_tf_vma_new_entry(): Returns an newly allocated or NULL.
> // Must only be called from user context.
> +// ... except, with inode-uprobes / task-finder2, it can be called from
> +// random tracepoints. So we cannot sleep after all.
> static struct __stp_tf_vma_entry *
> __stp_tf_vma_new_entry(void)
> {
> @@ -51,7 +53,7 @@ __stp_tf_vma_new_entry(void)
> size_t size = sizeof (struct __stp_tf_vma_entry);
>
> entry = (struct __stp_tf_vma_entry *) _stp_kmalloc_gfp(size,
> - STP_ALLOC_SLEEP_FLAGS);
> + STP_ALLOC_FLAGS);
> return entry;
> }
Urgh that hurts. Especially on memory constraint systems having to do
non-sleeping allocations. Isn't there any way we can prevent this? Or at
least detect that we are using a task_finder that doesn't notify us in
user context? I think there are other places that assume the task_finder
only notifies us about updates in user context, for example so we can
check the build-id. Having a taks_finder that only operates in atomic
contexts is pretty limiting.
Cheers,
Mark