linux-kernel - Re: [PATCHv2] tracing - avoid soft lockup in trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1301022889.14261.167.camel@gandalf.stny.rr.com>
Date:	Thu, 24 Mar 2011 23:14:49 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, fweisbec@...il.com,
	mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] tracing - avoid soft lockup in trace_pipe

On Thu, 2011-03-24 at 22:23 -0400, Steven Rostedt wrote:

> > > 
> > > 
> > > ---
> > > running following commands:
> > > 
> > >   # enable the binary option
> > >   echo 1 > ./options/bin
> > >   # disable context info option
> > >   echo 0 > ./options/context-info 
> > >   # tracing only events
> > >   echo 1 > ./events/enable
> > >   cat trace_pipe

OK, I'm trying to reproduce this, but I'm not able to.

I disabled preemption, recompiled and rebooted, and I did the above and
all I get is the numbers printing. But I can exit out with a simple ^C.

No soft lockups or anything.


I'm not saying that your patch is useless, it does seem to clean things
up. But I'm not seeing any lockups here.

The while loop will always exit when the ring buffer is empty.

You mean if the events are filling quicker than the loop then we have
this issue. Perhaps I'm not triggering enough events?

-- Steve

> > > 
> > > is causing lockup (in NON preemptive kernels) inside
> > > tracing_read_pipe function.
> > > 
> > > The reason are:
> > >  - bin/hex/raw output functions for events are set to
> > >    trace_nop_print function, which prints nothing and
> > >    returns TRACE_TYPE_HANDLED value
> > >  - LOST EVENT trace do not handle trace_seq overflow
> > > 
> > > These reasons force the while loop in tracing_read_pipe
> > > function never to break.
> > > 
> > > The attached patch fixies handling of lost event trace, and
> > > changes trace_nop_print to print minimal info, which is needed
> > > for the correct tracing_read_pipe processing.
> > > 
> > > v2 changes:
> > >  - omit the cond_resched changes by trace_nop_print changes
> > >  - WARN changed to WARN_ONCE and added info to be able
> > >    to find out the culprit
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/