From: wesolows@foobazco.org
To: "David S. Miller" <davem@redhat.com>
Cc: Jamie Lokier <jamie@shareable.org>,
sparclinux@vger.kernel.org, ultralinux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: A question about PROT_NONE on Sparc and Sparc64
Date: Wed, 30 Jun 2004 15:21:07 +0000 [thread overview]
Message-ID: <20040630152107.GA20438@foobazco.org> (raw)
In-Reply-To: <20040629221711.77f0fca5.davem@redhat.com>
On Tue, Jun 29, 2004 at 10:17:11PM -0700, David S. Miller wrote:
> > In include/asm-sparc/pgtsrmmu.h, there's:
> >
> > #define SRMMU_PAGE_NONE __pgprot(SRMMU_VALID | SRMMU_CACHE | \
> > SRMMU_PRIV | SRMMU_REF)
> > #define SRMMU_PAGE_RDONLY __pgprot(SRMMU_VALID | SRMMU_CACHE | \
> > SRMMU_EXEC | SRMMU_REF)
> >
> > This one bothers me. The difference is that PROT_NONE pages are not
> > accessible to userspace, and not executable.
> >
> > So userspace will get a fault if it tries to read a PROT_NONE page.
> >
> > But what happens when the kernel reads one? Don't those bits mean
> > that the read will succeed? I.e. write() on a PROT_NONE page will
> > succeed, instead of returning EFAULT?
> >
> > If so, this is a bug. A minor bug, perhaps, but nonetheless I wish to
> > document it.
>
> Yes this one is a bug and not intentional.
>
> Keith W., we need to fix this. Probably the simplest fix is just to
> drop the SRMMU_VALID bit.
Ok, I'll try this approach and see what happens.
--
Keith M Wesolowski
WARNING: multiple messages have this Message-ID (diff)
From: wesolows@foobazco.org
To: "David S. Miller" <davem@redhat.com>
Cc: Jamie Lokier <jamie@shareable.org>,
sparclinux@vger.kernel.org, ultralinux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: A question about PROT_NONE on Sparc and Sparc64
Date: Wed, 30 Jun 2004 08:21:07 -0700 [thread overview]
Message-ID: <20040630152107.GA20438@foobazco.org> (raw)
In-Reply-To: <20040629221711.77f0fca5.davem@redhat.com>
On Tue, Jun 29, 2004 at 10:17:11PM -0700, David S. Miller wrote:
> > In include/asm-sparc/pgtsrmmu.h, there's:
> >
> > #define SRMMU_PAGE_NONE __pgprot(SRMMU_VALID | SRMMU_CACHE | \
> > SRMMU_PRIV | SRMMU_REF)
> > #define SRMMU_PAGE_RDONLY __pgprot(SRMMU_VALID | SRMMU_CACHE | \
> > SRMMU_EXEC | SRMMU_REF)
> >
> > This one bothers me. The difference is that PROT_NONE pages are not
> > accessible to userspace, and not executable.
> >
> > So userspace will get a fault if it tries to read a PROT_NONE page.
> >
> > But what happens when the kernel reads one? Don't those bits mean
> > that the read will succeed? I.e. write() on a PROT_NONE page will
> > succeed, instead of returning EFAULT?
> >
> > If so, this is a bug. A minor bug, perhaps, but nonetheless I wish to
> > document it.
>
> Yes this one is a bug and not intentional.
>
> Keith W., we need to fix this. Probably the simplest fix is just to
> drop the SRMMU_VALID bit.
Ok, I'll try this approach and see what happens.
--
Keith M Wesolowski
next prev parent reply other threads:[~2004-06-30 15:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 3:05 A question about PROT_NONE on Sparc and Sparc64 Jamie Lokier
2004-06-30 3:05 ` Jamie Lokier
2004-06-30 5:17 ` David S. Miller
2004-06-30 5:17 ` David S. Miller
2004-06-30 5:17 ` David S. Miller
2004-06-30 15:21 ` wesolows [this message]
2004-06-30 15:21 ` wesolows
2004-06-30 8:28 ` Jakub Jelinek
2004-06-30 8:28 ` Jakub Jelinek
2004-06-30 20:54 ` David S. Miller
2004-06-30 20:54 ` David S. Miller
2004-06-30 22:52 ` Jamie Lokier
2004-06-30 22:52 ` Jamie Lokier
2004-07-01 5:25 ` David S. Miller
2004-07-01 5:25 ` David S. Miller
2004-07-01 7:47 ` David S. Miller
2004-07-01 7:47 ` David S. Miller
2004-07-02 1:03 ` A question about PROT_NONE on Sun4c 32-bit Sparc Jamie Lokier
2004-07-02 1:03 ` Jamie Lokier
2004-07-02 4:11 ` Keith M. Wesolowski
2004-07-02 4:11 ` Keith M. Wesolowski
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=20040630152107.GA20438@foobazco.org \
--to=wesolows@foobazco.org \
--cc=davem@redhat.com \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=ultralinux@vger.kernel.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.