On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert [off-list ref] wrote:

On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:

quoted

On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
[off-list ref] wrote:

quoted

quoted

quoted

You need to be a bit more careful tho. You must not allow RAM manage=

d by

quoted

quoted

quoted

quoted

the kernel to be mapped non-cachable.

Even if the user explicitly sets the O_SYNC flag? =C2=A0IMHO, it's a =

bug of

quoted

quoted

quoted

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"? =C2=A0Conflicts like this cause machine c=

hecks or

quoted

quoted

checkstops on many PowerPC implementations, we do not normally allow s=

uch

quoted

quoted

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? =C2=A0This is new to me. =C2=A0Could you elaborat=

e a bit?

That's called cache paradoxes. And yes they may be a problem.

Thanks.  I will prevent this from happening.

Besides that, existing =C2=A0application may have used mmap without O_SYN=

C 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).

That's my concern too.  But after all mmap without O_SYNC on I/O
devices should be deprecated.  A warning message in deprecation period
could reduce potential problem caused by this change.

- Leo