Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932830AbXA1U2H (ORCPT ); Sun, 28 Jan 2007 15:28:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932834AbXA1U2H (ORCPT ); Sun, 28 Jan 2007 15:28:07 -0500 Received: from smtp-out.google.com ([216.239.33.17]:63374 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932830AbXA1U2G (ORCPT ); Sun, 28 Jan 2007 15:28:06 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=LIqZU24yLxZhJ7IxCOpA8fsGyG0M0w2Qr0tZrLjNi2g2XIOiop2x4l0KSmwX+5DG6 ZAbqsSX16VdHPO2aJfbDw== Message-ID: Date: Sun, 28 Jan 2007 12:27:48 -0800 From: "Ken Chen" To: "Hugh Dickins" Subject: Re: [PATCH] Don't allow the stack to grow into hugetlb reserved regions Cc: "Adam Litke" , "Andrew Morton" , "William Irwin" , "David Gibson" , linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070125214052.22841.33449.stgit@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1542 Lines: 29 On 1/27/07, Hugh Dickins wrote: > Thanks, that's reassuring for the hugetlb case, and therefore Adam's > patch should not be delayed. But it does leave open the question I > was raising in the text you've snipped: if ia64 needs those stringent > REGION checks in its ia64_do_page_fault path, don't we need to add > them some(messy)how in the get_user_pages find_extend_vma path? I left it out because I need more time to digest what you said. After looked through ia64's page fault and get_user_pages, I've concluded that the bug scenario Adam described is impossible to trigger on ia64 due to various constrains and how the virtual address is laid out. For ia64, the hugetlb address region is reserved at the top of user space address. Stacks are below that region. Throw in the mix, we have two stacks, one memory stack that grows down and one register stack backing store that grows up. These two stacks are always in pair and grow towards each other. And lastly, we have virtual address holes in between regions. It's just impossible to grow any of these two stacks into hugetlb region no matter how I played it. So, AFAICS this bug doesn't apply to ia64 (and certainly not x86). The new check of is_hugepage_only_range() is really a noop for both arches. - Ken - 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/