public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
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

  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