From: Gabriel Paubert <paubert@iram•es>
To: Li Yang <leoli@freescale•com>
Cc: linuxppc-dev@ozlabs•org, Li Yang-R58472 <r58472@freescale•com>
Subject: Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
Date: Wed, 25 Nov 2009 12:30:23 +0100 [thread overview]
Message-ID: <20091125113023.GC12738@iram.es> (raw)
In-Reply-To: <2a27d3730911250007s62f31673p3358631996e8a451@mail.gmail.com>
On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
> <segher@kernel•crashing.org> wrote:
> >>> You need to be a bit more careful tho. You must not allow RAM managed by
> >>> the kernel to be mapped non-cachable.
> >>
> >> Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
> >> the application if it uses O_SYNC on main memory to be mmap'ed later.
> >> And we don't need to cover up the bug.
> >
> > Is that "embedded thinking"? Conflicts like this cause machine checks or
> > checkstops on many PowerPC implementations, we do not normally allow such
> > to be caused by userland.
>
> So what you are saying is that if the kernel has mapped a physical
> page as cacheable while user application is trying to map it as
> non-cacheable, there will be machine checks and checkstops rather than
> just performance drop? This is new to me. Could you elaborate a bit?
That's called cache paradoxes. And yes they may be a problem.
Besides that, existing application may have used mmap without O_SYNC on
I/O devices, knowing that the kernel would map them uncached. Your
patch would break them by using cached accesses (and it can cause
really hard to debug lockups, I've seen this, probably caused by
infinite retries on the PCI bus).
Gabriel
next prev parent reply other threads:[~2009-11-25 11:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 7:10 [RFC] powerpc/mm: honor O_SYNC flag for memory map Li Yang
2009-11-19 13:55 ` Kumar Gala
2009-11-20 3:00 ` Li Yang-R58472
2009-11-20 9:03 ` Benjamin Herrenschmidt
2009-11-20 9:23 ` Li Yang
2009-11-21 20:01 ` Segher Boessenkool
2009-11-25 8:07 ` Li Yang
2009-11-25 11:30 ` Gabriel Paubert [this message]
2009-11-26 7:43 ` Li Yang
2009-11-27 2:30 ` Paul Mackerras
2009-11-30 10:00 ` Li Yang
2009-11-26 21:26 ` Segher Boessenkool
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=20091125113023.GC12738@iram.es \
--to=paubert@iram$(echo .)es \
--cc=leoli@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=r58472@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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