linux-kernel - [PATCH, RFD] Unbreaking nommu mmap, v2

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-next>] [day] [month] [year] [list]

Message-ID: <483C3874.9010004@t-online.de>
Date:	Tue, 27 May 2008 18:36:04 +0200
From:	Bernd Schmidt <bernds_cb1@...nline.de>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	David Howells <dhowells@...hat.com>,
	Greg Ungerer <gerg@...pgear.com>,
	David McCullough <davidm@...pgear.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Matt Mackall <mpm@...enic.com>,
	"Wu, Bryan" <Bryan.Wu@...log.com>,
	Mike Frysinger <vapier.adi@...il.com>
Subject: [PATCH, RFD] Unbreaking nommu mmap, v2

A while ago (*) I sent out a patch to change mmap behaviour on nommu 
targets.  Currently, the kernel requires a munmap call for every mmap, 
with the exact same address range; this is inconsistent with behaviour 
on mmu systems, and complicates the malloc implementation in uClibc. 
uClibc's malloc requires that the UCLIBC_UCLINUX_BROKEN_MUNMAP config 
option is used, which introduces additional overhead, and isn't thread 
safe in the upstream version of uClibc.

To summarize the comments I got last time:
  - Better interface: MAP_SPLIT_PAGES has been renamed MAP_TRIM_EXCESS
  - Several people complained about a few Blackfin-specific items which
    I've hopefully eliminated.  MAP_TRIM_EXCESS was added to all
    architectures which can be compiled as nommu.
  - Matt Mackall was worried about increased overhead for programs using
    simplemalloc; however, simplemalloc (which does a mmap system call
    for every call to malloc) has incredible time and space overhead
    anyway, and it is to be hoped that either no one is using it, or they
    can switch to a sane malloc implementation.
  - David Howells worried that the kernel might get confused when
    unmapping a shared mmap of a file which has been mapped multiple
    times in the same process.  The intent seems to be to share the
    memory for these multiple maps, but this fails in practice even on
    an unpatched kernel: when I ran a test program to map the same file
    twice, I triggered this BUG_ON in add_nommu_vma:
                /* mappings are at the same address - this can only
                 * happen for shared-mem chardevs and shared file
                 * mappings backed by ramfs/tmpfs */
                BUG_ON(!(pvma->vm_flags & VM_SHARED));
    Also, even without this patch, I'm not sure how unmapping could be
    handled sanely in this case.

Apart from these comments, most people seemed to be ok with the basic 
approach.

I'd like to submit this for inclusion.  Any acks or objections?


Bernd

(*) http://lkml.org/lkml/2007/6/8/239
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif


View attachment "nommu-mmap3.diff" of type "text/x-patch" (25035 bytes)