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]

Message-ID: <4A519A70.50801@petalogix.com>
Date:	Mon, 06 Jul 2009 08:32:16 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	Arnd Bergmann <arnd@...db.de>
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

Arnd Bergmann wrote:
> On Friday 03 July 2009, Michal Simek wrote:
>
>   
>> I am trying to solve problem with mmap syscall on Microblaze which I have.
>> I am running mmap01 test program from LTP. In attachment is hacked
>> version and inline version is below too.
>>     
>
> Does this happen on microblaze-mmu or microblaze-nommu, or both?
> The mmap code for the two is very different.
>   
For MMU code.

> What file system is backing the temporary file?
>   
I tested it on nfs and initramfs.
The behavior on both has the same symptoms but on initramfs is program
much faster
which is presumtive.

If I run that test, 10times or more and see the output. For example
first 4 tests failed the rest
passed. I look at cpu internals and from syscalls/context switch I see
that that 4 tests which failed
are not interrupted. The rest is interrupted and that tests passed. I
have accurate log for it if you want to see that behavior.
Interruption caused that "anything" in kernel give a time to finish any
work which caused that mmap
memory is consistent.
This behavior is seen in my previous email that depends on time when is
listing called.
Is there any part of kernel which should take care about it?

Thanks for any suggestion.


> For -nommu, there are a number of ristrictions from
> Documentation/nommu-mmap.txt, in particular, MAP_FIXED is
> forbidden, as is PROT_WRITE with regular files. 
>   
This test can'b be run on noMMU.


Michal



>  
>   
>> Arnd: Anyway maybe worth to move sys_mmap2 to any generic location. What
>> do you think?
>>     
>
> Yes, that would be good. I actually have a patch for that somewhere in
> my playground repository, but it build-breaks some architectures in the
> current state. I'm planning to fix that (and do the same for execve
> and maybe some of the other remaining arch specific syscalls) at some
> point.
>
> 	Arnd <><
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

--
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/