linux-mips
[Top] [All Lists]

Re: access_ok and CONFIG_MIPS32 for 2.6

To: ralf@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Thu, 22 Jan 2004 19:32:27 +0900 (JST)
Cc: dimitri@sonycom.com, linux-mips@linux-mips.org
In-reply-to: <20040104210327.GA15475@sonycom.com> <20040122024529Z8224936-9616+669@linux-mips.org> <20040104.210532.74756709.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20040102194403.GB31092@linux-mips.org> <20040104.210532.74756709.anemo@mba.ocn.ne.jp> <20040104210327.GA15475@sonycom.com>
Sender: linux-mips-bounce@linux-mips.org
>>>>> On Sun, 4 Jan 2004 22:03:27 +0100, Dimitri Torfs <dimitri@sonycom.com> 
>>>>> said:
>> It seems there should be another definition of USER_DS for
>> CONFIG_MIPS32 in 2.6.

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

Now we can see this fix in CVS 2.6 tree (Thank you, Ralf).

Then, how about this one?

>>>>> On Sun, 04 Jan 2004 21:05:32 +0900 (JST), Atsushi Nemoto 
>>>>> <anemo@mba.ocn.ne.jp> said:
> Second, __access_ok for 64bit kernel is broken both 2.4 and 2.6.  It
> returns 0 if 'addr' + 'size' == TASK_SIZE (which should be OK).
> 
> 2.4 mips64:
> #define __access_ok(addr, size, mask)                                 \
>       (((mask) & ((addr) | ((addr) + (size)) | __ua_size(size))) == 0)
> 2.6:
> #define __access_ok(addr, size, mask)                                 \
>       (((signed long)((mask) & ((addr) | ((addr) + (size)) | 
> __ua_size(size)))) == 0)
> 
> I think these macros should be:
> 
> 2.4 mips64:
> #define __access_ok(addr, size, mask)                                 \
>       (((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size))) == 0)
> 2.6:
> #define __access_ok(addr, size, mask)                                 \
>       (((signed long)((mask) & ((addr) | ((addr) + (size) - 1) | 
> __ua_size(size)))) == 0)


For example, currently, access_ok(0xfffffff000UL, 0x1000) will return
0.  This must be legal (and this is a real problem for n64 mount
syscall which may grab user stack.  See copy_mount_option()).

---
Atsushi Nemoto

<Prev in Thread] Current Thread [Next in Thread>