Re: [PATCH 2/6] pstore: Add event tracing support
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2018-09-18 20:44:43
Also in:
linux-arm-kernel, linux-arm-msm, lkml
On Tue, 18 Sep 2018 23:22:48 +0530 Sai Prakash Ranjan [off-list ref] wrote:
On 9/18/2018 5:04 AM, Steven Rostedt wrote:quoted
It looks like pstore_event_call() gets called from a trace event. You can't call kmalloc() from one. One thing is that kmalloc has tracepoints itself. You trace those you just entered an infinite loop.Ok will remove it in v2. But any alternative way to do this?
I think I describe it below.
quoted
quoted
+ + event_call = fbuffer->trace_file->event_call; + if (!event_call || !event_call->event.funcs || + !event_call->event.funcs->trace) + goto fail_event; + + event = &fbuffer->trace_file->event_call->event; + + spin_lock_irqsave(&psinfo->buf_lock, flags); + + trace_seq_init(&iter->seq); + iter->ent = fbuffer->entry;I guess what you are doing is needing to translate the raw data into ascii output, and need the trace_iterator to do so. You are already under a psinfo->buf_lock. Add a dummy iterator to that and use it instead. trace_seq_init(&psinfo->iter->seq);quoted
+ event_call->event.funcs->trace(iter, 0, event);(psinfo->iter, 0 , event); etc.Sure, will update in v2.quoted
quoted
+ trace_seq_putc(&iter->seq, 0); + + if (seq->size > psinfo->bufsize) + seq->size = psinfo->bufsize; + + s = &iter->seq; + seq = &s->seq; + + record.buf = (char *)(seq->buffer); + record.size = seq->len; + psinfo->write(&record); + + spin_unlock_irqrestore(&psinfo->buf_lock, flags);You may also need to convert these spin_locks into raw_spin_locks as when PREEMPT_RT enters the kernel you don't want them to turn into mutexes. But that can be another patch.I will change this in v2, but can't we have it in same patch?
I suggested a separate patch because buf_lock is used elsewhere. Changing it to "raw_spin_lock" will affect more than just what this patch series does. Thus, I recommend making it a separate patch to keep this patch series from being more intrusive than it needs to be. Thanks! -- Steve