Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760565AbXKNRVZ (ORCPT ); Wed, 14 Nov 2007 12:21:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756698AbXKNRVQ (ORCPT ); Wed, 14 Nov 2007 12:21:16 -0500 Received: from ns.suse.de ([195.135.220.2]:45188 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756692AbXKNRVP (ORCPT ); Wed, 14 Nov 2007 12:21:15 -0500 Date: Wed, 14 Nov 2007 14:26:35 +0100 Message-ID: From: Takashi Iwai To: Nick Piggin Cc: Linus Torvalds , Linux Memory Management List , Linux Kernel Mailing List , Hugh Dickins , Andrew Morton , linux-ia64@vger.kernel.org, rth@twiddle.net, Jaya Kumar , krh@redhat.com, stefanr@s5r6.in-berlin.de, rolandd@cisco.com, mshefty@ichips.intel.com, hal.rosenstock@gmail.com, avi@qumranet.com, mchehab@infradead.org, dgilbert@interlog.com, Greg Kroah-Hartman , jgarzik@pobox.com, perex@perex.cz, Karsten Wiese Subject: Re: [rfc][patch] remove nopage In-Reply-To: <20071112015643.GA9291@wotan.suse.de> References: <20071112015643.GA9291@wotan.suse.de> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2210 Lines: 48 At Mon, 12 Nov 2007 02:56:43 +0100, Nick Piggin wrote: > > Hi all, > > This is a patch to remove 'nopage' from the tree. > > I've gone through all the drivers and converted them to use fault as best > I can. When using fault, I've also tried to use vmf->pgoff rather than the > virtual address to find the page (which is much preferred). Mostly it has > been OK, but DRM is a bit difficult, as it seems to use vma->vm_pgoff as > a 2nd dimension of addressing. > > I've also done some other things while going through at the code... > > Converted incorrect OOM returns to SIGBUS. OOM should only be returned as a > result of a memory allocation failure. We will actually want the fault path OOM > handling to be unified with the normal OOM killing path in future, and that > means the box will panic if panic_on_oom is set, or it will oom-kill random > processes before retrying the fault, etc. SIGBUS means something like > "physical address (ie. after translation) does not exist", which is appropriate > AFAIKS in all cases (but please double check). > > Got rid of some bogus looking "disallow mremap" checks that just check for > address > vma->vm_end. Am I missing something here? Presumably this is supposed > to prevent an mremap expanding the mapping outside the limit of the underlying > resource, but actually mremap will update vma->vm_end, and anyway this > condition is already checked in the page fault code. Others seem to get this > right by checking the underlying resource itself. Others don't seem to even > care. Might be a fair window for corruption / security problems here. Probably > we need a flag that explicitly prevents mremap() so driver writers don't have > to think too hard. > > Now all these are going to need to be split up properly, but if we can > take a look at this all together, the discussion will be more coherent ;) The changes in the sound stuff look OK. It works fine as long as I've tested. thanks, Takashi - 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/