Messages in this thread | | | Date | Wed, 14 Nov 2007 14:26:35 +0100 | From | Takashi Iwai <> | Subject | Re: [rfc][patch] remove nopage |
| |
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/
| |