Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > That sounds reasonable. However, I suspect that most NOMMU CPUs won't be
> > able to do that. In effect you're creating a third option, I think (MMU,
> > NOMMU, MPU).
>
> sure, but i'm not sure the MPU option would be mutually exclusive with
>
On 3/27/07, David Howells <[EMAIL PROTECTED]> wrote:
Note that it's not possible to shift windows around in response to faults
because fault reporting is asynchronous - the entire remaining instruction
queue will be executed *before* the exception is actually raised to the
kernel.
ah that
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > [*] The FRV, for example, does have some limited protection capability - but
> > it is really limited and not really useful in this case.
>
> how so ?
There are a limited set of protection registers (At least 8 insn and 8 data)
that can permit tiles
On 3/27/07, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
On Tue, 27 Mar 2007, Wu, Bryan wrote:
> Agree. MPU of Blackfin can provide some processes protection. But maybe
> at this moment just disable revoke for NOMMU is easier for further
> development. When we provide the MPU stuff, maybe we can
On 3/27/07, Pekka J Enberg [EMAIL PROTECTED] wrote:
On Tue, 27 Mar 2007, Wu, Bryan wrote:
Agree. MPU of Blackfin can provide some processes protection. But maybe
at this moment just disable revoke for NOMMU is easier for further
development. When we provide the MPU stuff, maybe we can enable
Mike Frysinger [EMAIL PROTECTED] wrote:
[*] The FRV, for example, does have some limited protection capability - but
it is really limited and not really useful in this case.
how so ?
There are a limited set of protection registers (At least 8 insn and 8 data)
that can permit tiles of
On 3/27/07, David Howells [EMAIL PROTECTED] wrote:
Note that it's not possible to shift windows around in response to faults
because fault reporting is asynchronous - the entire remaining instruction
queue will be executed *before* the exception is actually raised to the
kernel.
ah that would
Mike Frysinger [EMAIL PROTECTED] wrote:
That sounds reasonable. However, I suspect that most NOMMU CPUs won't be
able to do that. In effect you're creating a third option, I think (MMU,
NOMMU, MPU).
sure, but i'm not sure the MPU option would be mutually exclusive with
NOMMU ... in
On Tue, 27 Mar 2007, Wu, Bryan wrote:
> Agree. MPU of Blackfin can provide some processes protection. But maybe
> at this moment just disable revoke for NOMMU is easier for further
> development. When we provide the MPU stuff, maybe we can enable the
> revoke for NOMMU but MPU arch.
Yeah, MPU
On Mon, 2007-03-26 at 16:21 -0400, Mike Frysinger wrote:
> On 3/26/07, David Howells <[EMAIL PROTECTED]> wrote:
> > [*] The FRV, for example, does have some limited protection capability - but
> > it is really limited and not really useful in this case.
>
Sorry for late response.
> how so ?
On 3/26/07, David Howells <[EMAIL PROTECTED]> wrote:
[*] The FRV, for example, does have some limited protection capability - but
it is really limited and not really useful in this case.
how so ? the Blackfin processor lacks a MMU but it does have a MPU
(memory protection unit) which allows
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> We don't touch private mappings at all as they're a snapshot to the inode
> _before_ it was revoked. So private mappings don't really matter all: you
> don't see any new data after it has been revoked nor do you flush anything
> to the disk.
Okay,
Hi,
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> > revoke_mapping() is mostly same as munmap(2) except that it preserves the
> > vma but makes it VM_REVOKED. This means that if the process tries to
> > access the region it will SIGBUS and if it tries to remap the range it
> > will get EINVAL.
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> > I don't know, what does it do? Remember, once a NOMMU process thinks it
> > has the right to access a mapping, there's no way of stopping it doing so
> > short of killing the process.
>
> revoke_mapping() is mostly same as munmap(2) except that it
> With NOMMU as it stands, private mappings are private copies of the data, and
> have no impact on the page cache and get no updates from it. It's as if you
> took a private writable mapping, touched every page and then mprotect()'d it.
> This isn't necessarily ideal, but we're limited by the
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I'll touch up the changelog for nommu-hide-vm_mm-in-nommu-mode.patch and then
> I'll temporarily drop it so the blackfin guys can test their work, I guess.
Thanks.
As I said, I'm also not sure that revocation of VMAs is supportable on NOMMU,
so the
On Mon, 26 Mar 2007, David Howells wrote:
> I don't know, what does it do? Remember, once a NOMMU process thinks it has
> the right to access a mapping, there's no way of stopping it doing so short of
> killing the process.
revoke_mapping() is mostly same as munmap(2) except that it preserves
On Mon, 26 Mar 2007 12:25:18 +0100 David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Offending patch is
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/nommu-hide-vm_mm-in-nommu-mode.patch,
> > which
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> But what's more important is, can we do revoke_mapping() for NOMMU? AFAICT
> we can, we just need to scan all the global vmas, right?
I don't know, what does it do? Remember, once a NOMMU process thinks it has
the right to access a mapping, there's
Hi David,
On Mon, 26 Mar 2007, David Howells wrote:
> The reason is that, at the moment, VMAs are a global *shared* resource in
> NOMMU-mode. Each process has a list of global VMAs that it subscribes to, but
> that's it. This (a) slightly reduces the amount of metadata allocated
> (possibly),
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Offending patch is
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/nommu-hide-vm_mm-in-nommu-mode.patch,
> which seems rather dumb. Or at least, its changelog does a good job of
> making it look dumb.
On Mon, 26 Mar 2007 18:23:57 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
> arch, this is a fixing method when compiling failure on blackfin arch.
>
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> ---
>
>
On Mon, 26 Mar 2007, Wu, Bryan wrote:
> As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
> arch, this is a fixing method when compiling failure on blackfin arch.
What compile error is that? I don't see any #ifdef around ->vm_mm for
struct vm_area_struct in .
On Mon, 26 Mar
Hi folks,
As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
arch, this is a fixing method when compiling failure on blackfin arch.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
fs/revoke.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
Hi folks,
As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
arch, this is a fixing method when compiling failure on blackfin arch.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
fs/revoke.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
On Mon, 26 Mar 2007, Wu, Bryan wrote:
As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
arch, this is a fixing method when compiling failure on blackfin arch.
What compile error is that? I don't see any #ifdef around -vm_mm for
struct vm_area_struct in linux/mm.h.
On Mon,
On Mon, 26 Mar 2007 18:23:57 +0800 Wu, Bryan [EMAIL PROTECTED] wrote:
Hi folks,
As struct mm_struct vm_mm is hidden in struct vm_area_struct in NOMMU
arch, this is a fixing method when compiling failure on blackfin arch.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
fs/revoke.c |
Andrew Morton [EMAIL PROTECTED] wrote:
Offending patch is
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/nommu-hide-vm_mm-in-nommu-mode.patch,
which seems rather dumb. Or at least, its changelog does a good job of
making it look dumb.
Hi David,
On Mon, 26 Mar 2007, David Howells wrote:
The reason is that, at the moment, VMAs are a global *shared* resource in
NOMMU-mode. Each process has a list of global VMAs that it subscribes to, but
that's it. This (a) slightly reduces the amount of metadata allocated
(possibly), and
Pekka J Enberg [EMAIL PROTECTED] wrote:
But what's more important is, can we do revoke_mapping() for NOMMU? AFAICT
we can, we just need to scan all the global vmas, right?
I don't know, what does it do? Remember, once a NOMMU process thinks it has
the right to access a mapping, there's no
On Mon, 26 Mar 2007 12:25:18 +0100 David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
Offending patch is
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/nommu-hide-vm_mm-in-nommu-mode.patch,
which seems rather
On Mon, 26 Mar 2007, David Howells wrote:
I don't know, what does it do? Remember, once a NOMMU process thinks it has
the right to access a mapping, there's no way of stopping it doing so short of
killing the process.
revoke_mapping() is mostly same as munmap(2) except that it preserves the
Andrew Morton [EMAIL PROTECTED] wrote:
I'll touch up the changelog for nommu-hide-vm_mm-in-nommu-mode.patch and then
I'll temporarily drop it so the blackfin guys can test their work, I guess.
Thanks.
As I said, I'm also not sure that revocation of VMAs is supportable on NOMMU,
so the thing
With NOMMU as it stands, private mappings are private copies of the data, and
have no impact on the page cache and get no updates from it. It's as if you
took a private writable mapping, touched every page and then mprotect()'d it.
This isn't necessarily ideal, but we're limited by the lack
Pekka J Enberg [EMAIL PROTECTED] wrote:
I don't know, what does it do? Remember, once a NOMMU process thinks it
has the right to access a mapping, there's no way of stopping it doing so
short of killing the process.
revoke_mapping() is mostly same as munmap(2) except that it preserves
Hi,
Pekka J Enberg [EMAIL PROTECTED] wrote:
revoke_mapping() is mostly same as munmap(2) except that it preserves the
vma but makes it VM_REVOKED. This means that if the process tries to
access the region it will SIGBUS and if it tries to remap the range it
will get EINVAL.
On Mon, 26
Pekka J Enberg [EMAIL PROTECTED] wrote:
We don't touch private mappings at all as they're a snapshot to the inode
_before_ it was revoked. So private mappings don't really matter all: you
don't see any new data after it has been revoked nor do you flush anything
to the disk.
Okay, so
On 3/26/07, David Howells [EMAIL PROTECTED] wrote:
[*] The FRV, for example, does have some limited protection capability - but
it is really limited and not really useful in this case.
how so ? the Blackfin processor lacks a MMU but it does have a MPU
(memory protection unit) which allows
On Mon, 2007-03-26 at 16:21 -0400, Mike Frysinger wrote:
On 3/26/07, David Howells [EMAIL PROTECTED] wrote:
[*] The FRV, for example, does have some limited protection capability - but
it is really limited and not really useful in this case.
Sorry for late response.
how so ? the
On Tue, 27 Mar 2007, Wu, Bryan wrote:
Agree. MPU of Blackfin can provide some processes protection. But maybe
at this moment just disable revoke for NOMMU is easier for further
development. When we provide the MPU stuff, maybe we can enable the
revoke for NOMMU but MPU arch.
Yeah, MPU should
40 matches
Mail list logo
