All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.