linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Andrew Morton <akpm@digeo.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i386 uaccess to fixmap pages
Date: Fri, 9 May 2003 01:55:04 -0700	[thread overview]
Message-ID: <200305090855.h498t4b12921@magilla.sf.frob.com> (raw)
In-Reply-To: Andrew Morton's message of  Thursday, 8 May 2003 21:31:19 -0700 <20030508213119.58dd490d.akpm@digeo.com>

> This doesn't apply against Linus's current tree.

Ok.  I don't use bk, but I can update relative to the latest snapshot on
kernel.org.

> Your patch increases the kernel text by nearly 1%.  That's rather a lot for
> what is a fairly esoteric feature.

Agreed.  I hadn't thought about that angle.  I am open to suggestions on
other ways to make it work.

> Would it be possible to avoid this by just taking the fault and fixing
> things up in the exception handler?

There is no fault that would be taken.  The address is valid, but above
TASK_SIZE.  The purpose of access_ok is to say that it's ok to try it and
let it fault, because it's a user-visible address and not the kernel memory
mapped into the high part of every process's address space.  The accesses
that follow are done in kernel mode, so there is no fault for pages marked
as not user-visible.  The fixmap addresses are > TASK_SIZE and so fail the
__range_ok test, heretofore making access_ok return false.  Those are the
code paths leading to EFAULT that I mentioned.

So far I can't think of a better way to do it.

> You'll be wanting to parenthesise `size' and `type' here.

I didn't bother because the existing macros do not consistently
parenthesize their arguments and so if there were really any problems they
would already show.  But I agree it's what should be done.

> For some reason the patch causes gcc-2.95.3 to choke over the

You got me.  That version of gcc has many, many bugs and is long obsolete.
Random meaningless perturbations of the code might change its behavior.


Thanks,
Roland

  reply	other threads:[~2003-05-09  8:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09  2:03 [PATCH] i386 uaccess to fixmap pages Roland McGrath
2003-05-09  4:31 ` Andrew Morton
2003-05-09  8:55   ` Roland McGrath [this message]
2003-05-09  9:19     ` Andrew Morton
2003-05-09  9:40       ` Roland McGrath
2003-05-09 10:43       ` Roland McGrath
2003-05-09 11:42         ` Dave Jones
2003-05-09 11:55         ` Alan Cox
2003-05-09 12:40     ` Jamie Lokier
2003-05-09 16:06       ` Linus Torvalds
2003-05-09 16:38         ` Dave Hansen
2003-05-09 15:55           ` Martin J. Bligh
2003-05-09 18:20             ` William Lee Irwin III
2003-05-09 16:48           ` Linus Torvalds
2003-05-09 17:16             ` Dave Hansen
2003-05-10  3:26         ` H. Peter Anvin
2003-05-10 15:31           ` Jamie Lokier
2003-05-10 17:23             ` Ulrich Drepper
2003-05-10 19:23             ` H. Peter Anvin
2003-05-10 20:52               ` Jamie Lokier
2003-05-09 17:28 Chuck Ebbert
2003-05-09 17:49 ` Linus Torvalds

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=200305090855.h498t4b12921@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).