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
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:
> > [*] 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 ena
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 shou
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 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 gr
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
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.
O
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 pr
> 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 lac
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 thin
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
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 se
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
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), an
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]>
> ---
>
> fs
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 2
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(-)
In
20 matches
Mail list logo
