| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 6 Jul 2009 10:05:35 +0200 From: Arnd Bergmann <arnd@...db.de> To: michal.simek@...alogix.com Cc: Linux Kernel list <linux-kernel@...r.kernel.org>, LTP <ltp-list@...ts.sourceforge.net>, John Williams <john.williams@...alogix.com>, Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...ux-foundation.org>, Grant Likely <grant.likely@...retlab.ca>, subrata@...ux.vnet.ibm.com Subject: Re: mmap syscall problem On Monday 06 July 2009, Michal Simek wrote: > > Does this happen on microblaze-mmu or microblaze-nommu, or both? > > The mmap code for the two is very different. > > > For MMU code. Could this be a cache-aliasing problem? If your cache is 'virtually-indexed' (most architectures are 'physically-indexed'), the kernel may have written into different parts of the D-cache than what the user space is reading from. If you have a write-through cache, that can explain why you only see the stale data at the beginning of the page -- the cache controller is still busy writing back the data when you start reading it from DRAM through the cache alias. If this is your problem, then you need to implement flush_dcache_page() and other functions that maintain cache consistency. See Documentation/cachetlb.txt and http://www.linuxjournal.com/article/7105 Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists