Re: Add private syscalls to support NPTL

Klaus Kuehnhammer
2009-12-09T15:51:54Z

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

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

[-- Attachment #2: linux-2.6.25-nptl-page-not-writeable-fix.patch --]
[-- Type: application/octet-stream, Size: 453 bytes --]

--- aaa/arch/m68k/kernel/sys_m68k.c 2009-12-09 12:41:46.000000000 +0100
+++ bbb/arch/m68k/kernel/sys_m68k.c 2009-12-09 16:36:58.000000000 +0100
@@ -736,7 +736,7 @@
if (!pmd_present(*pmd))
goto bad_access;
pte = pte_offset_map_lock(mm, pmd, (unsigned long)mem, &ptl);
- if (!pte_present(*pte) || !pte_dirty(*pte)) {
+ if (!pte_write(*pte) || !pte_present(*pte) || !pte_dirty(*pte)) {
pte_unmap_unlock(pte, ptl);
goto bad_access;
}

[-- Attachment #3: Type: text/plain, Size: 1156 bytes --]

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 (klaus@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
> maxim@codesourcery.com
> (650) 331-3385 x724

--
Klaus Kuehnhammer
Bitstem Software
Wasnergasse 11/5
1200 Wien, Austria
+43 664 2133466
klaus@bitstem.com