All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitri Torfs <dimitri@sonycom.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
Date: Sun, 4 Jan 2004 22:03:27 +0100	[thread overview]
Message-ID: <20040104210327.GA15475@sonycom.com> (raw)
In-Reply-To: <20040104.210532.74756709.anemo@mba.ocn.ne.jp>

On Sun, Jan 04, 2004 at 09:05:32PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 2 Jan 2004 20:44:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> 
> >> Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
> >> 0x80000000 ?
> 
> ralf> There is a weird special case were 32-bit code running on a
> ralf> 64-bit kernel with c0_status.ux set will behave differently than
> ralf> on a 32-bit processor or with c0_status.ux clear.  The
> ralf> workaround for 64-bit kernels is to leave the top 32kB of the
> ralf> 2GB user virtual address space unused.  For sake of symmetry we
> ralf> do this on both 32-bit and 64-bit kernels.
> 
> Then, access_ok in 2.6 tree is broken, isn't it?
> 
> It seems there should be another definition of USER_DS for
> CONFIG_MIPS32 in 2.6.

Yes, I'm setting USER_DS to 0x80000000 for CONFIG_MIPS32:


--- linux-mips-2.6.orig/include/asm-mips/uaccess.h	2003-11-30 13:59:06.000000000 +0100
+++ linux.work/include/asm-mips/uaccess.h	2004-01-04 21:22:23.000000000 +0100
@@ -42,7 +42,12 @@
 #endif /* CONFIG_MIPS64 */
 
 #define KERNEL_DS	((mm_segment_t) { 0UL })
+
+#ifdef CONFIG_MIPS32
+#define USER_DS		((mm_segment_t) { 0x80000000UL })
+#else
 #define USER_DS		((mm_segment_t) { -TASK_SIZE })
+#endif
 
 #define VERIFY_READ    0
 #define VERIFY_WRITE   1


The USER_DS mask is also used in scall32-o32.S, scall64-64.S and
scall64-032.S. It think it would be cleaner if we replace there also
the ">= 0" check with the "== 0" check and add the correct size as you
suggested:


--- linux-mips-2.6.orig/arch/mips/kernel/scall64-64.S	2003-10-11 00:58:55.000000000 +0200
+++ linux.work/arch/mips/kernel/scall64-64.S	2004-01-04 21:45:45.000000000 +0100
@@ -119,10 +119,10 @@
 	bnez	v0, bad_alignment
 
 	LONG_L	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	LONG_ADDIU	a0, a1, 4
+	LONG_ADDIU	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */


--- linux-mips-2.6.orig/arch/mips/kernel/scall32-o32.S	2003-08-26 02:28:51.000000000 +0200
+++ linux.work/arch/mips/kernel/scall32-o32.S	2004-01-04 21:48:39.000000000 +0100
@@ -187,10 +187,10 @@
 	bnez	v0, bad_alignment
 
 	lw	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	addiu	a0, a1, 4
+	addiu	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */
@@ -280,11 +280,11 @@
 	bnez	v0, sigsegv
 
 	addu	v0, t0, 16			# v0 = usp + 16
-	addu	t1, v0, 12			# 3 32-bit arguments
+	addu	t1, v0, 11			# 3 32-bit arguments
 	lw	v1, TI_ADDR_LIMIT($28)
 	or	v0, v0, t1
 	and	v1, v1, v0
-	bltz	v1, efault
+	bnez	v1, efault
 
 	move	a0, a1				# shift argument registers
 	move	a1, a2



--- linux-mips-2.6.orig/arch/mips/kernel/scall64-64.S	2003-10-11 00:58:55.000000000 +0200
+++ linux.work/arch/mips/kernel/scall64-64.S	2004-01-04 21:45:45.000000000 +0100
@@ -119,10 +119,10 @@
 	bnez	v0, bad_alignment
 
 	LONG_L	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	LONG_ADDIU	a0, a1, 4
+	LONG_ADDIU	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */



Dimitri

  reply	other threads:[~2004-01-04 21:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-02 14:59 access_ok and CONFIG_MIPS32 for 2.6 Dimitri Torfs
2004-01-02 19:44 ` Ralf Baechle
2004-01-04 12:05   ` Atsushi Nemoto
2004-01-04 21:03     ` Dimitri Torfs [this message]
2004-01-22 10:32     ` Atsushi Nemoto

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=20040104210327.GA15475@sonycom.com \
    --to=dimitri@sonycom.com \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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.