Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752611AbZIUQK7 (ORCPT ); Mon, 21 Sep 2009 12:10:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751114AbZIUQK2 (ORCPT ); Mon, 21 Sep 2009 12:10:28 -0400 Received: from gate.crashing.org ([63.228.1.57]:54929 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251AbZIUQK0 (ORCPT ); Mon, 21 Sep 2009 12:10:26 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87FFD936-384D-4A04-AD6D-90BBDD3DAD18@kernel.crashing.org> Cc: Linux/PPC Development , Linux Kernel Development , Linux Test Project Content-Transfer-Encoding: 7bit From: Segher Boessenkool Subject: Re: [LTP] mmapstress03 weirdness? (fwd) Date: Mon, 21 Sep 2009 18:10:32 +0200 To: Geert Uytterhoeven X-Mailer: Apple Mail (2.753.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1772 Lines: 57 > if (mmap((caddr_t)(1UL << (POINTER_SIZE - 1)) - pagesize, > (size_t)((1UL << (POINTER_SIZE - 1)) - pagesize), > PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED| > MAP_SHARED, 0, 0) > != (caddr_t)-1) > With 32-bit userland, this boils down to: > > | mmap addr 0x7fff0000 size 0x7fff0000 > | mmap returned 0x7fff0000 > > i.e. mmap() succeeds, Yes, on a powerpc64 kernel, every 32-bit userspace process has 4GB available (well, except the lowest few pages). The process text sits normally at 1M and the shared libs around 256M. > but (1) the test expects it to fail, so the test returns > TFAIL, That's a bug in the test then. > but (2) ltp-pan still reports that the tests passed? Sounds like another bug. > In addition, sometimes mmapstress03 fails due to SEGV. I created a > small test > program that just does the above mmap(), and depending on the > distro and what > else I print later it crashes with a SEGV, too. Probably this > happens because > the mmap() did succeed, and corrupted some existing mappings, It probably killed the stack, which sits all the way up near 4G. > JFYI, with 64-bit userland, this boils down to: > > | mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000 > | mmap returned 0xffffffffffffffff > > i.e. mmap() fails as expected, and the test succeeds. It tries to map space that is reserved for the kernel (c000...) > Does all of this sound OK? Seems to me everything works fine, except the tests themselves. Segher -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/