linux-kernel - Re: [PATCH 2/2] tracing - putting cond_resched into tace

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]

Date:	Mon, 14 Mar 2011 10:28:46 -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: [PATCH 2/2] tracing - putting cond_resched into tace_pipe loop

On Mon, 2011-03-14 at 15:18 +0100, Jiri Olsa wrote:


> > I'm not sure that this needs the signal_pending() or the break, or even
> > the cond_resched(). Perhaps the first patch fixes the bug. But that
> > while loop does not block, and it should just spin enough to fill a
> > page. If it is not filling the page then that's a bug.
> 
> well, if there are no "event lost" messages and the flags are set
> to the "bin or raw" and you trace events only, then the page
> is not be filled.
> 
> But as there'll be allways lost events, the page will be populated
> and it will get out of the loop.

There's two loops, I'm talking about the inner one, which will break out
when there are no events left to process.

The "waitagain" calls into tracing_wait_pipe which has the
signal_pending() attribute. It should also block, or return -EAGAIN if
the caller is not blocking.

> 
> > 
> > Jiri,
> > 
> > Can you reproduce the bug with just he first patch? Actually, I can
> > reproduce it on vanilla, I'll apply your first patch and see if that
> > fixes things. If not, then we need to find out why and fix those.
> 
> The first patch fixies the 'lost evets' trace, so the loop is escaped
> when the page is full.
> (I was going to send some change for first patch WARN_ON -> WARN_ONCE)

Yes, I was going to recommend doing that too.

> 
> I think in case there are no 'lost events' and we have the conditions
> I describe, we need the cond_resched call.

No we don't.

As for non preempt kernels, honestly, I don't care about latencies. If
you are worried about latencies, don't run a non preempt kernel. I do
care if it goes into an infinite loop, or never processes signals, which
would be a bug. But long running times in the kernel on a non preempt
kernel. Well, that's just part of the game.

-- Steve

> 
> I'll send new patch version shortly.
> 
> thanks,
> jirka
> > 
> > -- Steve
> > 
> > 


--
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/