Hello again, It looks like the issue is caused by the page being write-protected. Adding !pte_write(*pte) to the checks seems to fix this, it goes into page fault and reloads the page entry writable. A patch is attached.
I'm not entirely comfortable w/this solution... I understand why calling do_page_fault w/a fixed RMW flag makes the write access work on the next iteration, but why would this page lack the write flag in the first place? Or, conversely, why does glibc call cmpxchg on a mem location in a non-writeable page? Regarding the freescale kernel issues: Is there another kernel version we could try? best regards, Klaus PS I'm putting the list back on CC
linux-2.6.25-nptl-page-not-writeable-fix.patch
Description: Binary data
On 09.12.2009, at 13:14, Maxim Kuvyrkov wrote: > Klaus Kuehnhammer wrote: >> Hi! >> Thanks for the quick reply! >> It's a 2.6.25 kernel from the mid-2008 freescale BSP, w/the NPTL patches for >> the latest toolchain. >> Linux version 2.6.25 (kl...@uvirt) (gcc version 4.4.1 (Sourcery G++ Lite >> 4.4-54) ) > > This kernel has several known issues, some of them can be triggered by NPTL > support. > >> I haven't run this in the debugger yet so i don't know for certain. From the >> address the oops gives, it's definitely in sys_atomic_cmpxchg_32. I added a >> printk, and the offending address comes in via the mem param, so yes, I >> guess the first *mem is the place. > > Would you please provide a dump of the code near the place where the oops > occurs, you should be able to do that with `m68k-linux-gnu-objdump -d vmlinux > | grep -C 80 00021e50'. And, of cause, a testcase will be of great help for > tracking this down. > > Thanks, > > -- > Maxim Kuvyrkov > CodeSourcery > [email protected] > (650) 331-3385 x724 -- Klaus Kuehnhammer Bitstem Software Wasnergasse 11/5 1200 Wien, Austria +43 664 2133466 [email protected]
