Re: [gamin] inotify kernel panic

[Robert Love <rml ximian com>]

On Sat, 2004-09-18 at 01:31 -0400, John McCutchan wrote:

> > Ran another test to reduce the variables.  Compiled a new vanilla 2.6.8.1 
> > kernel with conservative optimization flags.  Booted into said kernel and 
> > rebult gamin with same flags.  Ran through testgam procedure and panic'd 
> > at same place.

You should not compile the kernel with anything but the default
compilation flags.  This includes optimizations.  Do not make them more
or less optimizing.

In multiple places we require the behavior of the optimizer.  Besides,
no one ever deviates from the defaults and thus there is zero testing.

> I need to see the trace, I have looked at the code path starting from
> the timer code, and I can't find any place that could cause a NULL
> pointer dereference on a UP system. On an SMP system, the way the timer
> was disabled it could have potentially caused a NULL pointer
> dereference. But without seeing the stack trace that involves inotify I
> can't fix this bug. 
> 
> Rob, I am wondering if del_timer_sync should actually be declared when
> the kernel is compiled with preempt ? Is it possible for the kernel to
> get preempted while executing a timer callback?

Nope.  Timers run in a softirq and softirqs are not preemptive.

The only thing that can interrupt a softirq is an interrupt handler.

	Robert Love