All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>
Subject: Re: [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled	checks in tracing hot path
Date: Mon, 25 Jan 2010 20:37:48 -0500	[thread overview]
Message-ID: <4B5E476C.9030303@redhat.com> (raw)
In-Reply-To: <20100126011303.GA29148@Krystal>

Mathieu Desnoyers wrote:
> * Frederic Weisbecker (fweisbec@gmail.com) wrote:
>> On Mon, Jan 25, 2010 at 05:14:16PM -0500, Masami Hiramatsu wrote:
>>> Frederic Weisbecker wrote:
>>>> On Fri, Jan 22, 2010 at 07:34:51AM -0500, Mathieu Desnoyers wrote:
>>>>> * Steven Rostedt (rostedt@goodmis.org) wrote:
>>>>>> On Thu, 2010-01-21 at 23:09 -0500, Mathieu Desnoyers wrote:
>>>>>>> * Steven Rostedt (rostedt@goodmis.org) wrote:
>>>>>>
>>>>>>>> Hmm, interesting. Maybe something like that might work. But what if
>>>>>>>> CONFIG_PREEMPT is enabled but CONFIG_FREEZER is not?
>>>>>>>
>>>>>>> Then you may want to make the function tracer depend on CONFIG_FREEZER,
>>>>>>> but maybe Masami has other ideas ?
>>>>>>
>>>>>> egad no! This is just to help add guarantees to those that use the
>>>>>> function tracer that when the tracing is disabled, it is guaranteed that
>>>>>> no more tracing will be called by the function tracer. Currently,
>>>>>> nothing relies on this. But we may add cases that might need this.
>>>>>
>>>>> Yep, identifying tracer quiescent state can become handy.
>>>>>
>>>>>>
>>>>>> In fact, only those that need this requirement would need to do this
>>>>>> trick. Anyway, we could make those depend on CONFIG_FREEZER, but that
>>>>>> just seems to be a strange dependency.
>>>>>
>>>>> This makes me wonder (question for Masami)...
>>>>>
>>>>> static int __kprobes check_safety(void)
>>>>> {
>>>>>         int ret = 0;
>>>>> #if defined(CONFIG_PREEMPT) && defined(CONFIG_FREEZER)
>>>>>         ret = freeze_processes();
>>>>>         if (ret == 0) {
>>>>>                 struct task_struct *p, *q;
>>>>>                 do_each_thread(p, q) {
>>>>>                         if (p != current && p->state == TASK_RUNNING &&
>>>>>                             p->pid != 0) {
>>>>>                                 printk("Check failed: %s is running\n",p->comm);
>>>>>                                 ret = -1;
>>>>>                                 goto loop_end;
>>>>>                         }
>>>>>                 } while_each_thread(p, q);
>>>>
>>>>
>>>>
>>>> How does that deal with kernel threads that don't freeze?
>>>
>>> Hmm, right. It can't handle non-freezable kernel threads.
>>>
>>>> Also freezing every processes seems a bit of a heavy thing for that.
>>>> Looks like a synchronize_tasks() would be really useful.
>>>
>>> Sure :-)
>>> Maybe, I'd better remove booster support on preemptive kernel until then.
>>
>>
>> I don't know as I haven't looked deeper into check_safety(), but does the
>> fact we have non-freezable tasks break the assumptions that make
>> kprobes booster safe? If so then yeah, may be deactivate it for now.
>>
> 
> In the case of check_safety, it's not a bug per se if a task happens to
> be non freezable. freeze_processes() will likely return a non-zero
> value, and the whole check_safety will therefore return that value, so
> standard breakpoints will be used instead.

Hmm, unfortunately no, because freeze_processes() doesn't count
non-freezable threads...

---
                todo = 0;
                read_lock(&tasklist_lock);
                do_each_thread(g, p) {
                        if (frozen(p) || !freezeable(p))
                                continue;

                        if (!freeze_task(p, sig_only))
                                continue;

                        /*
                         * Now that we've done set_freeze_flag, don't
                         * perturb a task in TASK_STOPPED or TASK_TRACED.
                         * It is "frozen enough".  If the task does wake
                         * up, it will immediately call try_to_freeze.
                         */
                        if (!task_is_stopped_or_traced(p) &&
                            !freezer_should_skip(p))
                                todo++;
                } while_each_thread(g, p);
                read_unlock(&tasklist_lock);
                if (!todo || time_after(jiffies, end_time))
                        break;
---

So, it can return 0 if there is non-freezable threads running.

Thank you,


-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


  reply	other threads:[~2010-01-26  1:38 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-22  1:16 [RFC PATCH 00/10] Ftrace functions hashlist Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 01/10] ftrace: Generalize the function hashlist from function profiler Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 02/10] ftrace: Ensure tracing has really stopped before leaving unregister_ftrace_graph Frederic Weisbecker
2010-01-22  1:51   ` Steven Rostedt
2010-01-22  2:04     ` Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path Frederic Weisbecker
2010-01-22  2:05   ` Steven Rostedt
2010-01-22  2:28     ` Mathieu Desnoyers
2010-01-22  3:12       ` Steven Rostedt
2010-01-22  4:09         ` Mathieu Desnoyers
2010-01-22  4:52           ` Steven Rostedt
2010-01-22 12:34             ` Mathieu Desnoyers
2010-01-22 14:54               ` Masami Hiramatsu
2010-01-25 20:58               ` Frederic Weisbecker
2010-01-25 22:14                 ` Masami Hiramatsu
2010-01-26  0:41                   ` Frederic Weisbecker
2010-01-26  1:13                     ` Mathieu Desnoyers
2010-01-26  1:37                       ` Masami Hiramatsu [this message]
2010-01-27 21:55                         ` [PATCH tracing/kprobes] kprobes: Disable booster when CONFIG_PREEMPT=y Masami Hiramatsu
2010-01-28  1:08                           ` Mathieu Desnoyers
2010-01-28  4:21                           ` Ananth N Mavinakayanahalli
2010-01-29  9:21                           ` Ingo Molnar
2010-01-29 11:30                             ` Peter Zijlstra
2010-01-29 14:52                             ` Masami Hiramatsu
2010-01-29 17:08                               ` Mathieu Desnoyers
2010-01-29 17:15                                 ` Peter Zijlstra
2010-01-29 17:27                                   ` Mathieu Desnoyers
2010-01-29 17:32                                     ` Masami Hiramatsu
2010-01-22  2:43     ` [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path Frederic Weisbecker
2010-01-22  3:05       ` Steven Rostedt
2010-01-25 20:52         ` Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 04/10] ftrace: Ensure buffers are visibles to tracing callbacks right away Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 05/10] ftrace: Drop buffer check in function profiler callbacks Frederic Weisbecker
2010-01-25  6:17   ` Lai Jiangshan
2010-01-30 20:47     ` Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 06/10] ftrace: Release the function hlist if we don't need it anymore Frederic Weisbecker
2010-01-25  6:41   ` Lai Jiangshan
2010-01-30 21:14     ` Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 07/10] ftrace: Make the function hashlist concurrently usable Frederic Weisbecker
2010-01-22  1:16 ` [PATCH 08/10] tracing: Simplify test for function_graph tracing Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 09/10] tracing: Use the hashlist for graph function Frederic Weisbecker
2010-01-25  8:50   ` Lai Jiangshan
2010-01-30 21:19     ` Frederic Weisbecker
2010-01-22  1:16 ` [RFC PATCH 10/10] ftrace: Factorize search and insertion in the function hashlist Frederic Weisbecker

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=4B5E476C.9030303@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.