parisc mmap: private file maps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Currently, the perl testsuite fails the lib/locale.t test causing the
Debian package build to fail if tests are not disabled:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721206

This is also perl bug #119567.

What happens is the test uses mmap to open a few hundred locale files
with MAP_PRIVATE:

...
open("/usr/lib/locale/de_LI.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) =  4
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xffe93000
close(4)                                = 0
open("/usr/lib/locale/de_LI.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = 4
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENOMEM (Cannot allocate memory)

As can be seen, these are all small maps.

However, in arch_get_unmapped_area(), we allocate a shared area for all file
maps:

static unsigned long get_shared_area(struct address_space *mapping,
                unsigned long addr, unsigned long len, unsigned long pgoff)
{
        struct vm_unmapped_area_info info;

        info.flags = 0;
        info.length = len;
        info.low_limit = PAGE_ALIGN(addr);
        info.high_limit = TASK_SIZE;
        info.vm_unmapped_area = PAGE_MASK & (SHMLBA - 1);
        info.align_offset = (get_offset(mapping) + pgoff) << PAGE_SHIFT;
        return vm_unmapped_area(&info);
}

As can be seen, align_mask is set to "PAGE_MASK & (SHMLBA - 1)".  This is
0x3ff000. vm_unmapped_area() adds this to len when it allocates the area.
So, at a minimum, we allocate just under 4 MB for each file map and rapidly
run out of memory for private file maps.

This results from the PA8800/PA8900 aliasing requirements.

Aside from the limited number of private file maps, I'm not sure the current
implementation is correct. In a private map, a write to the area is not supposed
to affect the underlying object, and I assume any other existing maps to the
object. It's also undefined whether changes to the underlying object after the
mmap call are visible within the private map.

So, I'm thinking it would be better to just allocate an unshared area and copy
the file region to it.  But this seems ugly.

The other alternative is to change the align_mask and align_offset for private maps in some way. But this seems tricky given the aliasing requirements. Maybe the alignment requirements could be relaxed on processors where aliasing isn't an
issue.

Thoughts?

Dave

--
John David Anglin    dave.anglin@xxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux