From: Takashi Iwai <tiwai@suse.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hugh Dickins <hugh@veritas.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ia64@vger.kernel.org, rth@twiddle.net,
Jaya Kumar <jayakumar.lkml@gmail.com>,
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 <greg@kroah.com>,
jgarzik@pobox.com, perex@perex.cz,
Karsten Wiese <annabellesgarden@yahoo.de>
Subject: Re: [rfc][patch] remove nopage
Date: Wed, 14 Nov 2007 13:26:35 +0000 [thread overview]
Message-ID: <s5hhcjpdkl0.wl%tiwai@suse.de> (raw)
In-Reply-To: <20071112015643.GA9291@wotan.suse.de>
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
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hugh Dickins <hugh@veritas.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ia64@vger.kernel.org, rth@twiddle.net,
Jaya Kumar <jayakumar.lkml@gmail.com>,
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 <greg@kroah.com>,
jgarzik@pobox.com, perex@perex.cz,
Karsten Wiese <annabellesgarden@yahoo.de>
Subject: Re: [rfc][patch] remove nopage
Date: Wed, 14 Nov 2007 14:26:35 +0100 [thread overview]
Message-ID: <s5hhcjpdkl0.wl%tiwai@suse.de> (raw)
In-Reply-To: <20071112015643.GA9291@wotan.suse.de>
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
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hugh Dickins <hugh@veritas.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-ia64@vger.kernel.org, rth@twiddle.net,
Jaya Kumar <jayakumar.lkml@gmail.com>,
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 <greg@kroah.com>,
jgarzik@pobox.com, perex@perex.cz,
Karsten Wiese <annabellesgarden@yahoo.de>
Subject: Re: [rfc][patch] remove nopage
Date: Wed, 14 Nov 2007 14:26:35 +0100 [thread overview]
Message-ID: <s5hhcjpdkl0.wl%tiwai@suse.de> (raw)
In-Reply-To: <20071112015643.GA9291@wotan.suse.de>
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-11-14 13:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-12 1:56 [rfc][patch] remove nopage Nick Piggin
2007-11-12 1:56 ` Nick Piggin
2007-11-12 1:56 ` Nick Piggin
2007-11-12 2:04 ` Jeff Garzik
2007-11-12 2:04 ` Jeff Garzik
2007-11-12 2:04 ` Jeff Garzik
2007-11-12 4:36 ` Nick Piggin
2007-11-12 4:36 ` Nick Piggin
2007-11-12 4:36 ` Nick Piggin
2007-11-12 8:16 ` Jon Masters
2007-11-12 8:19 ` Jon Masters
2007-11-14 13:26 ` Takashi Iwai [this message]
2007-11-14 13:26 ` Takashi Iwai
2007-11-14 13:26 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hhcjpdkl0.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=akpm@linux-foundation.org \
--cc=annabellesgarden@yahoo.de \
--cc=avi@qumranet.com \
--cc=dgilbert@interlog.com \
--cc=greg@kroah.com \
--cc=hal.rosenstock@gmail.com \
--cc=hugh@veritas.com \
--cc=jayakumar.lkml@gmail.com \
--cc=jgarzik@pobox.com \
--cc=krh@redhat.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mchehab@infradead.org \
--cc=mshefty@ichips.intel.com \
--cc=npiggin@suse.de \
--cc=perex@perex.cz \
--cc=rolandd@cisco.com \
--cc=rth@twiddle.net \
--cc=stefanr@s5r6.in-berlin.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.