Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751276AbWJKNOS (ORCPT ); Wed, 11 Oct 2006 09:14:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161049AbWJKNOR (ORCPT ); Wed, 11 Oct 2006 09:14:17 -0400 Received: from amsfep17-int.chello.nl ([213.46.243.15]:61967 "EHLO amsfep14-int.chello.nl") by vger.kernel.org with ESMTP id S1751276AbWJKNOQ (ORCPT ); Wed, 11 Oct 2006 09:14:16 -0400 Subject: Re: Removing MAX_ARG_PAGES (request for comments/assistance) From: Peter Zijlstra To: Ollie Wild Cc: linux-kernel@vger.kernel.org, parisc-linux@lists.parisc-linux.org, Linus Torvalds , Arjan van de Ven , Ingo Molnar , linux-mm@kvack.org, Andrew Morton , Andi Kleen , linux-arch@vger.kernel.org, David Howells In-Reply-To: <65dd6fd50610101705t3db93a72sc0847cd120aa05d3@mail.gmail.com> References: <65dd6fd50610101705t3db93a72sc0847cd120aa05d3@mail.gmail.com> Content-Type: text/plain Date: Wed, 11 Oct 2006 15:14:20 +0200 Message-Id: <1160572460.2006.79.camel@taijtu> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1909 Lines: 49 On Tue, 2006-10-10 at 17:05 -0700, Ollie Wild wrote: > + vma->vm_flags &= ~VM_EXEC; > + // FIXME: Are the next two lines sufficient, or do I need to > + // do some additional magic? > + vma->vm_flags |= mm->def_flags; > + vma->vm_page_prot = protection_map[vma->vm_flags & 0x7]; Yeah, you'll need to change the PTEs for those pages you created by calling get_user_page() by calling an mprotect like function; perhaps something like: struct vm_area_struct *prev; unsigned long vm_flags = vma->vm_flags; s/vma->vm_flags/vm_flags/g err = mprotect_fixup(vma, &prev, vma->vm_start, vma->vm_end, vm_flags); BUG_ON(prev != vma); mprotect_fixup will then set the new protection on all PTEs and update vma->vm_flags and vma->vm_page_prot. > + /* Move stack pages down in memory. */ > + if (stack_shift) { > + // FIXME: Verify the shift is OK. > + What exactly are you wondering about? the call to move_vma looks sane to me > + /* This should be safe even with overlap because we > + * are shifting down. */ > + ret = move_vma(vma, vma->vm_start, > + vma->vm_end - vma->vm_start, > + vma->vm_end - vma->vm_start, > + vma->vm_start - stack_shift); > + if (ret & ~PAGE_MASK) { > + up_write(&mm->mmap_sem); > + return ret; > + } > } - 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/