Re: timerfd read does not return - was probably fixed in 3.4.38

[Stanislav Meduna <stano@meduna.org>]

On 18.04.2013 11:11, Stanislav Meduna wrote:

> from a new log that includes syscall tracing it seems that a thread
> waiting in a timerfd is woken, but does not return from the read:

For the record, the problem seems to be the issue that the
http://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v3.4-rt&id=52cecaa
fixed in v3.4.38-rt52 (tracing: Fix free of probe entry by calling
call_rcu_sched()). A kernel with just this commit reverted stalled
once per ~4 hours, with this one it did not stall in ~24h (I will
surely try to run it longer).

Why did is always manifest itself by hanging in return from timerfd
read (and not e.g. when timer_create and friends were used) is beyond
me, but there will be a reason.

Sorry for the false alarm, it was already fixed at the time I reported
it - it is just that one wants to know the reason before updating
to a brand new kernel with 750+ other changes.


A general question: I am seeing a few recent changes in the tracing
code. Is it generally safe to have at least latency histogram enabled
in the production code, or is it advised not to compile these features
in? I'd like to see the latencies the customer is getting in the real
environment, but if the code is considered as work-in-progress,
it is better to play it safe.

Thanks
-- 
                                           Stano