| To: | Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
|---|---|
| Subject: | Re: mips64 _access_ok fix |
| From: | Ralf Baechle <ralf@linux-mips.org> |
| Date: | Thu, 11 Sep 2003 16:16:29 +0200 |
| Cc: | linux-mips@linux-mips.org |
| In-reply-to: | <20030911.134323.03974731.nemoto@toshiba-tops.co.jp> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <20030911.124350.41627177.nemoto@toshiba-tops.co.jp> <20030911.134323.03974731.nemoto@toshiba-tops.co.jp> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.4.1i |
On Thu, Sep 11, 2003 at 01:43:23PM +0900, Atsushi Nemoto wrote: > I know this fix is not complete. __access_ok(0, 0, __access_mask) > will return 0. > > I could not find out good expression (i.e. no conditional branch) to > handle this case. > > I suppose nobody do take care of this since addr 0 is invalid pointer > anyway. That behaviour of __access_ok() is actually ok; __access_ok only needs to return non-zero only for addresses >= TASK_SIZE. For two reason the case you're mentioning is not a problem. As you say 0 is (usually) a bad pointer value so if the kernel tries to dereference it, an TLB exception is going to happen and the exception handling code will deal with the case. Second the size argument is zero and after all that means the kernel won't touch the address range anyway because hey, it's zero-length! Ralf |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: unresolved symbol dptoli, Ralf Baechle |
|---|---|
| Next by Date: | Re: Some Question about the kernel module on MIPS64, Ralf Baechle |
| Previous by Thread: | Re: mips64 _access_ok fix, Atsushi Nemoto |
| Next by Thread: | Re: mips64 _access_ok fix, Atsushi Nemoto |
| Indexes: | [Date] [Thread] [Top] [All Lists] |