From: Maxim Kuvyrkov <maxim@codesourcery.com>
To: Klaus Kuehnhammer <klaus@bitstem.com>
Cc: linux-m68k@vger.kernel.org, Jin Zhengxiong-R64188 <R64188@freescale.com>
Subject: Re: Add private syscalls to support NPTL
Date: Thu, 10 Dec 2009 12:18:42 +0300 [thread overview]
Message-ID: <4B20BCF2.9050005@codesourcery.com> (raw)
In-Reply-To: <F139AB5C-ED7E-4664-AB7E-AD9EFFEF9DDD@bitstem.com>
On 12/9/09 6:44 PM, Klaus Kuehnhammer wrote:
> 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?
It may have the write bit cleared (or have a readonly bit set) when the
page should be copied-on-write. What strange is why !pte_dirty()
doesn't imply !pte_write(). The cmpxchg code was ported from
arm.c:traps.c; here is the comment to the patch that changed
!pte_write() to !pte_dirty in ARM's implementation:
|pte_write() just says that the page _may_ be writable. It doesn't say
|that the MMU is programmed to allow writes. If pte_dirty() doesn't
|return true, that means that the page is _not_ writable from userspace.
|If you write to it from kernel mode (without using put_user) you'll
|bypass the MMU read-only protection and may end up writing to a page
|owned by two separate processes.
From the above it seems that your patch is safe. However, it may be
papering over the consequences of a different bug. Is there a linux
memory management expert around to comment on this?
...
> Regarding the freescale kernel issues: Is there another kernel
> version we could try?
I sent a link to this thread to Jason (Jin) who's working at Freescale
and he suggested you try the following patch and see if it fixes the
problem. This patch fixes a cache handling problem on some of the
ColdFire CPUs.
-------------------
diff --git a/arch/m68k/coldfire/signal.c b/arch/m68k/coldfire/signal.c
index 38671c4..b1b2bfb 100644
--- a/arch/m68k/coldfire/signal.c
+++ b/arch/m68k/coldfire/signal.c
@@ -608,9 +608,8 @@ static inline int rt_setup_ucontext(struct ucontext
__user *uc,
static inline void push_cache(unsigned long vaddr)
{
-#if 0
-// JKM -- need to add into the old cpushl cache stuff
- cf_cache_push(__pa(vaddr), 8);
+#ifdef CONFIG_M547X_8X
+ flush_icache_range(vaddr, vaddr + 8);
#endif
}
-------------------
Regards,
--
Maxim Kuvyrkov
CodeSourcery
maxim@codesourcery.com
(650) 331-3385 x724
next prev parent reply other threads:[~2009-12-10 9:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 21:48 Add private syscalls to support NPTL Maxim Kuvyrkov
2009-08-17 22:11 ` Andreas Schwab
2009-08-18 7:15 ` Maxim Kuvyrkov
2009-08-18 8:06 ` Andreas Schwab
2009-08-18 8:56 ` Maxim Kuvyrkov
2009-08-18 9:22 ` Geert Uytterhoeven
2009-08-18 9:36 ` Maxim Kuvyrkov
2009-08-18 18:18 ` Andreas Schwab
2009-08-23 20:21 ` Maxim Kuvyrkov
2009-08-25 19:43 ` Maxim Kuvyrkov
2009-08-28 10:51 ` Maxim Kuvyrkov
2009-10-02 9:59 ` Maxim Kuvyrkov
2009-10-26 15:01 ` Maxim Kuvyrkov
2009-10-28 1:19 ` Finn Thain
2009-10-28 6:54 ` Maxim Kuvyrkov
2009-10-28 16:38 ` Finn Thain
2009-11-06 8:38 ` Finn Thain
2009-11-06 8:59 ` Maxim Kuvyrkov
2009-11-10 4:07 ` Finn Thain
2009-11-10 4:20 ` Brad Boyer
2009-11-10 10:51 ` Maxim Kuvyrkov
2009-11-10 16:11 ` Finn Thain
2009-08-17 22:18 ` Andreas Schwab
2009-08-18 7:10 ` Maxim Kuvyrkov
2009-08-18 2:28 ` Brad Boyer
2009-08-18 7:07 ` Maxim Kuvyrkov
2009-08-18 23:40 ` Brad Boyer
2009-08-19 8:06 ` Maxim Kuvyrkov
2009-08-19 8:35 ` Andreas Schwab
2009-12-07 8:38 ` Maxim Kuvyrkov
2009-12-09 10:25 ` Klaus Kuehnhammer
2009-12-09 11:05 ` Maxim Kuvyrkov
[not found] ` <DBFD40BF-19FC-47DF-8A7C-B71261AFBD85@parq.net>
[not found] ` <4B1F9492.6030604@codesourcery.com>
2009-12-09 15:44 ` Klaus Kuehnhammer
2009-12-10 9:18 ` Maxim Kuvyrkov [this message]
2009-12-11 14:01 ` Geert Uytterhoeven
2009-12-11 16:23 ` Maxim Kuvyrkov
2009-12-17 17:53 ` Maxim Kuvyrkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B20BCF2.9050005@codesourcery.com \
--to=maxim@codesourcery.com \
--cc=R64188@freescale.com \
--cc=klaus@bitstem.com \
--cc=linux-m68k@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox