linux-kernel - Re: mmap syscall problem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Jul 2009 21:14:55 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Michal Simek <michal.simek@...alogix.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	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 Mon, Jul 06, 2009 at 02:07:06PM +0200, Michal Simek wrote:
> Arnd Bergmann wrote:
> > 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.
> >   
> I don't think so because we run that test on Microblaze without caches
> and test failed too.
> I think that this is sufficient test to tell that the problem is not
> relate with caches.
> 
Not necessarily, even on platforms that manage aliases in hardware
mappings that violate the aliasing constraints can still result in
undefined behaviour, this really depends more on your cache controller
and MMU than anything else. I notice that microblaze sets SHMLBA to
PAGE_SIZE, you may want to see if this test still breaks after bumping it
up to something like PAGE_SIZE * 4.

This is unfortunately one of the areas where what POSIX says is possible
and what hardware can support are at odds (you can look through
arch/sh/mm/mmap.c for a better idea).
--
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/