On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert <paub...@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 >> <seg...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
