All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: "Keith M. Wesolowski" <wesolows@foobazco.org>
Cc: "David S. Miller" <davem@redhat.com>,
	linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: A question about PROT_NONE on Sun4c 32-bit Sparc
Date: Fri, 02 Jul 2004 01:03:49 +0000	[thread overview]
Message-ID: <20040702010349.GF8950@mail.shareable.org> (raw)
In-Reply-To: <20040630030503.GA25149@mail.shareable.org>

Hi Keith,

David Miller suggested I ask you specifically about the Sun4 & Sun4c
32-bit Sparc ports of Linux.  He's confirmed a bug in the SRMMU 32-bit
Sparc port, and I just wanted you to confirm it isn't in the other
32-bit Sparc ports.

I would like to know if the Sun4 and Sun4c ports have the same bug.
I'm guessing not, but it's not clear to me from the code.

In linux-2.6.5/include/asm-sparc/pgtsun4.h (pgtsun4c.h is similar):

#define _SUN4C_PAGE_VALID        0x80000000
#define _SUN4C_PAGE_SILENT_READ  0x80000000   /* synonym */
#define _SUN4C_PAGE_DIRTY        0x40000000
#define _SUN4C_PAGE_SILENT_WRITE 0x40000000   /* synonym */
...
#define _SUN4C_PAGE_READ         0x00800000   /* implemented in software */
#define _SUN4C_PAGE_WRITE        0x00400000   /* implemented in software */
#define _SUN4C_PAGE_ACCESSED     0x00200000   /* implemented in software */
#define _SUN4C_PAGE_MODIFIED     0x00100000   /* implemented in software */
...
#define _SUN4C_READABLE		(_SUN4C_PAGE_READ|_SUN4C_PAGE_SILENT_READ|\
				 _SUN4C_PAGE_ACCESSED)
#define _SUN4C_WRITEABLE	(_SUN4C_PAGE_WRITE|_SUN4C_PAGE_SILENT_WRITE|\
				 _SUN4C_PAGE_MODIFIED)
...
#define SUN4C_PAGE_NONE		__pgprot(_SUN4C_PAGE_PRESENT)
#define SUN4C_PAGE_SHARED	__pgprot(_SUN4C_PAGE_PRESENT|_SUN4C_READABLE|\
					 _SUN4C_PAGE_WRITE)
#define SUN4C_PAGE_READONLY	__pgprot(_SUN4C_PAGE_PRESENT|_SUN4C_READABLE)

SUN4C_PAGE_NONE corresponds to PROT_NONE mmap memory protection.

The question is whether PROT_NONE pages are readable by the _kernel_.
I.e. whether write() would successfully read from those pages.

From the names of the above macros, I'm guessing not.  There's nothing
to indicate that they would be.  I just wanted you to confirm, thanks.

(In the SRMMU 32-Sparc version, PROT_NONE pages _are_ readable in the
kernel, because of the way they are implemented by making them
priveleged pages.)

(By the way, as the sun4 files don't contain a definition of
_SUN4_PAGE_FILE or pgoff_to_pte, but the sun4c one do, I guess the
sun4 sub-architecture doesn't build in 2.6 but sun4c does?)

Thanks,
-- Jamie

WARNING: multiple messages have this Message-ID (diff)
From: Jamie Lokier <jamie@shareable.org>
To: "Keith M. Wesolowski" <wesolows@foobazco.org>
Cc: "David S. Miller" <davem@redhat.com>,
	linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org
Subject: A question about PROT_NONE on Sun4c 32-bit Sparc
Date: Fri, 2 Jul 2004 02:03:49 +0100	[thread overview]
Message-ID: <20040702010349.GF8950@mail.shareable.org> (raw)
In-Reply-To: <20040630030503.GA25149@mail.shareable.org>

Hi Keith,

David Miller suggested I ask you specifically about the Sun4 & Sun4c
32-bit Sparc ports of Linux.  He's confirmed a bug in the SRMMU 32-bit
Sparc port, and I just wanted you to confirm it isn't in the other
32-bit Sparc ports.

I would like to know if the Sun4 and Sun4c ports have the same bug.
I'm guessing not, but it's not clear to me from the code.

In linux-2.6.5/include/asm-sparc/pgtsun4.h (pgtsun4c.h is similar):

#define _SUN4C_PAGE_VALID        0x80000000
#define _SUN4C_PAGE_SILENT_READ  0x80000000   /* synonym */
#define _SUN4C_PAGE_DIRTY        0x40000000
#define _SUN4C_PAGE_SILENT_WRITE 0x40000000   /* synonym */
...
#define _SUN4C_PAGE_READ         0x00800000   /* implemented in software */
#define _SUN4C_PAGE_WRITE        0x00400000   /* implemented in software */
#define _SUN4C_PAGE_ACCESSED     0x00200000   /* implemented in software */
#define _SUN4C_PAGE_MODIFIED     0x00100000   /* implemented in software */
...
#define _SUN4C_READABLE		(_SUN4C_PAGE_READ|_SUN4C_PAGE_SILENT_READ|\
				 _SUN4C_PAGE_ACCESSED)
#define _SUN4C_WRITEABLE	(_SUN4C_PAGE_WRITE|_SUN4C_PAGE_SILENT_WRITE|\
				 _SUN4C_PAGE_MODIFIED)
...
#define SUN4C_PAGE_NONE		__pgprot(_SUN4C_PAGE_PRESENT)
#define SUN4C_PAGE_SHARED	__pgprot(_SUN4C_PAGE_PRESENT|_SUN4C_READABLE|\
					 _SUN4C_PAGE_WRITE)
#define SUN4C_PAGE_READONLY	__pgprot(_SUN4C_PAGE_PRESENT|_SUN4C_READABLE)

SUN4C_PAGE_NONE corresponds to PROT_NONE mmap memory protection.

The question is whether PROT_NONE pages are readable by the _kernel_.
I.e. whether write() would successfully read from those pages.

>From the names of the above macros, I'm guessing not.  There's nothing
to indicate that they would be.  I just wanted you to confirm, thanks.

(In the SRMMU 32-Sparc version, PROT_NONE pages _are_ readable in the
kernel, because of the way they are implemented by making them
priveleged pages.)

(By the way, as the sun4 files don't contain a definition of
_SUN4_PAGE_FILE or pgoff_to_pte, but the sun4c one do, I guess the
sun4 sub-architecture doesn't build in 2.6 but sun4c does?)

Thanks,
-- Jamie

  parent reply	other threads:[~2004-07-02  1:03 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
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 ` Jamie Lokier [this message]
2004-07-02  1:03   ` A question about PROT_NONE on Sun4c 32-bit Sparc 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=20040702010349.GF8950@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=wesolows@foobazco.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.