[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10651

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> 2010-10-14 20:47:17 UTC ---
http://sourceware.org/ml/systemtap/2010-q4/msg00034.html
appears to be a new sighting.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10651

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> 2010-11-27 23:54:44 UTC ---
commit 3fd1c490 switches to atomic_t flags to the timer callback functions
to defeat mod_timer() calls that might overlap a del_timer_sync.
commit f2b610b does likewise for the transport layer timers.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-07-08 14:56 -------
Not recently seen.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=10651

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-05 14:47 -------
> > Something is calling mod_timer with a timer->function==NULL.
> 
> This seems to indicate either memory corruption, or the memory was freed and
> cleared by the next owner.

I wonder if this was another case of bug #10854.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10651

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/10651] very rare BUG_ON kernel/timer.c:619 due to runtime/time.c

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2009-09-18 20:06 -------
(In reply to comment #0)
> Something is calling mod_timer with a timer->function==NULL.

This seems to indicate either memory corruption, or the memory was freed and
cleared by the next owner.  It seems like particularly poor timing for the
function pointer to have been valid enough to enter the handler but invalid at
the end of the handler.

> It appears as if the _stp_kill_time function is needlessly racy
> (amongst the stp_timer_reregister flag, which should probably be
> an atomic_t), and the del_timer_sync()'s.  It wouldn't hurt to
> plop a synchronize_sched() in there too before the free_percpu
> goo.

Can you get a crash dump?  I'd like to confirm that _stp_kill_time was actually
attempted, possibly by looking at the backtraces on other cpus and checking if
stp_time==NULL.

The promises of del_timer_sync when it returns are that the handler is not
active and the timer is not queued.  I think this actually makes the reregister
flag superfluous.  It should then be perfectly safe to free the memory, unless
the for_each_online_cpu somehow missed one of the timers...


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10651

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.