Messages in this thread | | | Date | Sat, 4 Oct 2008 18:24:10 -0700 | From | "Jesse Brandeburg" <> | Subject | Re: [RFC PATCH 02/12] On Tue, 23 Sep 2008, David Miller wrote: |
| |
On Sat, Oct 4, 2008 at 4:02 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Sat, 4 Oct 2008, Jiri Kosina wrote: >> On Fri, 3 Oct 2008, Jesse Brandeburg wrote: >> > Our experience is different. We are also testing with the "protection >> > patch" reverted. >> > We see that the problem specifically comes and goes when >> > removing/adding the use of set_memory_ro/set_memory_rw to the driver. >> >> But if this patch (which is an obvious workaround, compared to the other >> patches which fix real bugs, right?) would be catching some malicious >> accessess to the mapped EEPROM, there should be stacktraces present in the >> kernel log, right?
yes, but I think it is just changing timing, i don't see any backtraces either.
> Exactly. The access to a ro region results in a fault. I have nowhere > seen that trigger, but I can reproduce the trylock() WARN_ON, which > confirms that there is concurrent access to the NVRAM registers. The > backtrace pattern is similar to the one you have seen.
are you still getting WARN_ON *with* all the mutex based fixes already applied?
with the mutex patches in place (without protection patch) we are still reproducing the issue, until we apply the set_memory_ro patch. I had no luck on friday setting a hardware breakpoint on memory access with kgdb to catch the writer with a breakpoint.
| |