[RFC] powerpc/mm: honor O_SYNC flag for memory map

[Li Yang]

On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert <paubert at iram.es> wrote:
> 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 at 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.

Thanks.  I will prevent this from happening.

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

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