All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	RT <linux-rt-users@vger.kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH RT 3.18] ring-buffer: Mark irq_work as HARD_IRQ to prevent deadlocks
Date: Thu, 16 Apr 2015 16:28:58 +0200	[thread overview]
Message-ID: <552FC72A.8060709@siemens.com> (raw)
In-Reply-To: <552FC6B1.1040000@linutronix.de>

On 2015-04-16 16:26, Sebastian Andrzej Siewior wrote:
> On 04/16/2015 04:06 PM, Jan Kiszka wrote:
>> ftrace may trigger rb_wakeups while holding pi_lock which will also be
>> requested via trace_...->...->ring_buffer_unlock_commit->...->
>> irq_work_queue->raise_softirq->try_to_wake_up. This quickly causes
>> deadlocks when trying to use ftrace under -rt.
>>
>> Resolve this by marking the ring buffer's irq_work as HARD_IRQ.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> I'm not yet sure if this doesn't push work into hard-irq context that
>> is better not done there on -rt.
> 
> everything should be done in the soft-irq.
> 
>>
>> I'm also not sure if there aren't more such cases, given that -rt turns
>> the default irq_work wakeup policy around. But maybe we are lucky.
> 
> The only thing that is getting done in the hardirq is the FULL_NO_HZ
> thingy. I would be _very_ glad if we could keep it that way.

Then - to my current understanding - we need an NMI-safe trigger for
soft-irq work. Is there anything like this existing already? Or can we
still use the IPI-based kick without actually doing the work in hard-irq
context?

Jan

> 
>>  kernel/trace/ring_buffer.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
>> index f4fbbfc..6a1939e 100644
>> --- a/kernel/trace/ring_buffer.c
>> +++ b/kernel/trace/ring_buffer.c
>> @@ -1252,6 +1252,7 @@ rb_allocate_cpu_buffer(struct ring_buffer *buffer, int nr_pages, int cpu)
>>  	init_irq_work(&cpu_buffer->irq_work.work, rb_wake_up_waiters);
>>  	init_waitqueue_head(&cpu_buffer->irq_work.waiters);
>>  	init_waitqueue_head(&cpu_buffer->irq_work.full_waiters);
>> +	cpu_buffer->irq_work.work.flags = IRQ_WORK_HARD_IRQ;
>>  
>>  	bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
>>  			    GFP_KERNEL, cpu_to_node(cpu));
>>
> 
> Sebastian
> 

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2015-04-16 14:29 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 14:06 [PATCH RT 3.18] ring-buffer: Mark irq_work as HARD_IRQ to prevent deadlocks Jan Kiszka
2015-04-16 14:12 ` Steven Rostedt
2015-04-16 14:26 ` Sebastian Andrzej Siewior
2015-04-16 14:28   ` Jan Kiszka [this message]
2015-04-16 14:57     ` Sebastian Andrzej Siewior
2015-04-16 15:31       ` Jan Kiszka
2015-04-16 15:10     ` Steven Rostedt
2015-04-16 15:29       ` Jan Kiszka
2015-04-16 15:33         ` Sebastian Andrzej Siewior
2015-04-16 16:28         ` [PATCH RT 3.18] irq_work: Provide a soft-irq based queue Jan Kiszka
2015-04-20  8:03           ` Mike Galbraith
2015-04-23  6:11             ` Mike Galbraith
2015-04-23  6:29               ` Jan Kiszka
2015-04-23  6:58                 ` Mike Galbraith
2015-04-23  7:14                   ` Jan Kiszka
2015-04-23  6:50               ` Jan Kiszka
2015-04-23  7:01                 ` Mike Galbraith
2015-04-23  7:12                   ` Jan Kiszka
2015-04-23  7:12                     ` Jan Kiszka
2015-04-23  7:19                     ` Mike Galbraith
2015-04-23  7:19                       ` Mike Galbraith
2015-04-23 21:00                       ` Steven Rostedt
2015-04-24  6:54                         ` Mike Galbraith
2015-04-24  9:00                           ` Jan Kiszka
2015-04-24  9:59                             ` Mike Galbraith
2015-04-25  7:20                             ` Mike Galbraith
2015-04-25  7:26                               ` Jan Kiszka
2015-05-18 19:52                                 ` Sebastian Andrzej Siewior

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=552FC72A.8060709@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --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.