From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932606AbWEXO6p (ORCPT ); Wed, 24 May 2006 10:58:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932642AbWEXO6p (ORCPT ); Wed, 24 May 2006 10:58:45 -0400 Received: from silver.veritas.com ([143.127.12.111]:21070 "EHLO silver.veritas.com") by vger.kernel.org with ESMTP id S932606AbWEXO6p (ORCPT ); Wed, 24 May 2006 10:58:45 -0400 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="38470987:sNHT22094356" Date: Wed, 24 May 2006 15:57:34 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: Christoph Lameter cc: Peter Zijlstra , Andrew Morton , Linus Torvalds , David Howells , Rohit Seth , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: remove VM_LOCKED before remap_pfn_range and drop VM_SHM In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2006 14:57:39.0921 (UTC) FILETIME=[66FF3C10:01C67F42] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 May 2006, Christoph Lameter wrote: > > Remove VM_LOCKED before remap_pfn range from device drivers and get rid of > VM_SHM. Okay, that is rather a nice cleanup. I've held off from doing it, and have discouraged one or two others from doing it, because there's a number of other things to be checked thereabouts (witness the way vfc_dev.c is or'ing flags it has no business to change: but you've rightly preserved that existing behaviour for now, however bad it may be); and there's VM_RESERVED (or most of its or'ings) to be removed too. But what you have looks nice, and no way does it prevent further cleanup later; though I've not wanted to bother maintainers repeatedly. Of course, you don't need this patch in order to proceed with migrating VM_LOCKED areas, because this patch is no more than a cleanup of irrelevance. Well, somewhat worse than irrelevance: when a driver unilaterally sets VM_LOCKED on a vma, then mm->locked_vm goes wild when the vma is unmapped: doesn't matter at exit, but bad if before. > remap_pfn_range() already sets VM_IO. There is no need to set VM_SHM since > it does nothing. VM_LOCKED is of no use since the remap_pfn_range does > not place pages on the LRU. The pages are therefore never subject to > swap anyways. Remove all the vm_flags settings before calling > remap_pfn_range. > > After removing all the vm_flag settings no use of VM_SHM is left. > Drop it. > > Signed-off-by: Christoph Lameter Acked-by: Hugh Dickins