Hi Abdul, On Tue 07-11-17 11:28:54, Michal Hocko wrote: > On Tue 07-11-17 15:20:29, Abdul Haleem wrote: > > Hi, > > > > Today's next kernel fails to boot on Power 7 Machine with below errors > > in boot log messages. > > > > 'Uhuuh, elf segement at 0000000010040000 requested but the memory is > > mapped already' > > > > It was introduced with commit: > > > > 0692229e : fs/binfmt_elf.c: drop MAP_FIXED usage from elf_map > > Weird. Clashes shouldn't really happen. Maybe power is doing something > different from other platforms. Could you apply the following debugging > patch to see what is going on there? Did you have chance to test with this debugging patch, please? > --- > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 0abc30d681ae..f098aaf60039 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -361,8 +361,28 @@ static unsigned long elf_vm_mmap(struct file *filep, unsigned long addr, > return map_addr; > > if ((type & MAP_FIXED) && map_addr != addr) { > - pr_info("Uhuuh, elf segement at %p requested but the memory is mapped already\n", > - (void*)addr); > + struct mm_struct *mm = current->mm; > + struct vm_area_struct *vma; > + pr_info("Uhuuh, elf segement at %p requested but the memory is mapped already, got %p\n", > + (void*)addr, (void*)map_addr); > + down_read(&mm->mmap_sem); > + vma = find_vma(mm, addr); > + if (vma) { > + const char *name; > + pr_info("Clashing vma [%lx, %lx] flags:%lx", vma->vm_start, vma->vm_end, vma->vm_flags); > + name = arch_vma_name(vma); > + if (!name) { > + if (vma->vm_start <= mm->brk && > + vma->vm_end >= mm->start_brk) > + name = "[heap]"; > + else if (vma->vm_start <= vma->vm_mm->start_stack && > + vma->vm_end >= vma->vm_mm->start_stack) > + name = "[stack]"; > + } > + pr_cont(" name:%s\n", name); > + } else > + pr_info("Uhm, no clashing VMA\n"); > + up_read(&mm->mmap_sem); > return -EAGAIN; > } > > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html