From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 14 Nov 2007 14:26:35 +0100 Message-ID: From: Takashi Iwai Subject: Re: [rfc][patch] remove nopage In-Reply-To: <20071112015643.GA9291@wotan.suse.de> References: <20071112015643.GA9291@wotan.suse.de> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: 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 List-ID: 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org