[Bug libc/34282] FAIL: stdlib/test-bz22786

https://sourceware.org/bugzilla/show_bug.cgi?id=34282

--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to John David Anglin from comment #8)
> Here is strace output:
> [pid  3996] mmap2(NULL, 2147483675, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x78a75000
> [pid  3996] getrandom("\xec\xbf\x79\xa3\xf1\x8d\x8e\x4b", 8, GRND_NONBLOCK)
> = 8
> [pid  3996] openat(AT_FDCWD, "/tmp/support_blob_repeat-FwIwK2",
> O_RDWR|O_CREAT|O_EXCL, 0600) = 3
> [pid  3996] unlink("/tmp/support_blob_repeat-FwIwK2") = 0
> [pid  3996] fallocate(3, 0, 0, 4194304) = 0
> [pid  3996] mmap2(0x78a75000, 4194304, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)

It looks like hppa is not 

> [pid  3996] munmap(0x78a75000, 2147483675) = 0
> [pid  3996] close(3)                    = 0
> [pid  3996] symlink(".", "/tmp/bz22786.FK11i9/symlink") = 0
> [pid  3996] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=NULL} ---
> [pid  3996] +++ killed by SIGSEGV +++

(In reply to John David Anglin from comment #8)
> Here is strace output:
> [pid  3996] mmap2(NULL, 2147483675, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x78a75000
> [pid  3996] getrandom("\xec\xbf\x79\xa3\xf1\x8d\x8e\x4b", 8, GRND_NONBLOCK)
> = 8
> [pid  3996] openat(AT_FDCWD, "/tmp/support_blob_repeat-FwIwK2",
> O_RDWR|O_CREAT|O_EXCL, 0600) = 3
> [pid  3996] unlink("/tmp/support_blob_repeat-FwIwK2") = 0
> [pid  3996] fallocate(3, 0, 0, 4194304) = 0
> [pid  3996] mmap2(0x78a75000, 4194304, PROT_READ|PROT_WRITE,
> MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
> [pid  3996] munmap(0x78a75000, 2147483675) = 0
> [pid  3996] close(3)                    = 0
> [pid  3996] symlink(".", "/tmp/bz22786.FK11i9/symlink") = 0
> [pid  3996] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=NULL} ---
> [pid  3996] +++ killed by SIGSEGV +++


It seems to be a hppa limitation due its virtually-indexed cache:

arch/parisc/kernel/sys_parisc.c:

103 static unsigned long arch_get_unmapped_area_common(struct file *filp,
104         unsigned long addr, unsigned long len, unsigned long pgoff,
105         unsigned long flags, enum mmap_allocation_direction dir)
106 {
[...]
118         do_color_align = 0;
119         if (filp || (flags & MAP_SHARED))
120                 do_color_align = 1;
121         filp_pgoff = GET_FILP_PGOFF(filp);
122
123         if (flags & MAP_FIXED) {
124                 /* Even MAP_FIXED mappings must reside within TASK_SIZE */
125                 if (TASK_SIZE - len < addr)
126                         return -EINVAL;
127
128                 if ((flags & MAP_SHARED) && filp &&
129                     (addr - shared_align_offset(filp_pgoff, pgoff))
130                                 & (SHM_COLOUR - 1))
131                         return -EINVAL;
132                 return addr;
133         }


The 'filp_pgoff' comes from the file's kernel address_space pointer (unknowable
and unpredictable from userspace). I think we can harden the allocate_big to:

1. Create and fallocate the backing file first.
2. Fill it via a *non-fixed MAP_SHARED* mapping (mmap (NULL, ...)). The kernel
places it at a *correctly-colored* address, which both performs the fill and
reveals the color: mapping_colour = addr & (mapping_alignment-1).
3. Reserve the region over-allocated by mapping_alignment, then position its
base so target % mapping_alignment == mapping_colour, trimming the head/tail
slack.
4. The stride is a multiple of mapping_alignment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.