All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Bombe <andreas.bombe@munich.netsurf.de>
To: Bjorn Wesen <bjorn@sparta.lu.se>
Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>, linux-kernel@vger.kernel.org
Subject: Re: Address translation
Date: Sat, 25 Nov 2000 00:28:23 +0100	[thread overview]
Message-ID: <20001125002822.D2324@storm.local> (raw)
In-Reply-To: <20001123212315.C4886@storm.local> <Pine.LNX.3.96.1001123214139.14437A-100000@medusa.sparta.lu.se>
In-Reply-To: <Pine.LNX.3.96.1001123214139.14437A-100000@medusa.sparta.lu.se>; from bjorn@sparta.lu.se on Thu, Nov 23, 2000 at 10:04:18PM +0100

On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
> On Thu, 23 Nov 2000, Andreas Bombe wrote:
> > > I may be wrong on this, but I thought that copy_{to,from}_user are
> > > only necessary if the address range you are accessing might cause a
> > > fault which Linux cannot handle (ie. one which would cause the
> > > application to segfault if it accessed that memory). If it is only a
> > 
> > It is wrong.  copy_*_user handle the page faults, whether they are good
> > faults (swapped out, copy on write) or bad faults (illegal access).
> > Without these macros you get the "unable to handle kernel page fault"
> > oops message if a fault occurs.
> 
> Yes but only if it's a real fault, not if the address range actually is
> a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user
> does not do the access in any different way than a "manual" access or
> memcpy does, it just adds a .fixup section that tells the do_page_fault
> handler that it should not segfault the kernel itself if the copy takes a
> big fault at any point, instead it should jump to the fixup which makes
> the copy routine return an error message.

You're right, I remembered wrong.

> > >  (1) In a "top half" thread, can I now access this memory without the
> > >      access macros (since I know the address range is valid)?
> > 
> > The address is valid, the pages probably aren't.  In fact, extending the
> > address space only creates read-only mappings to the global zeroed page
> > if I remember right.
> 
> But it does not matter that the pages aren't there physically, any kind of
> access (including an access from kernel-mode) will bring about the same
> COW/change-on-write mechanism as copy_to_user or a user-mode access would.

However these faults can let you sleep (swap-in, or swap-out to make
room for a COW page).  That's defined for the uaccess macros, but might
come very unexpected with a memcpy.  Unexpected sleeps alone can make a
crash if the surrounding code does not allow it.

It's a moot point anyway, memcpy with user space is illegal.

-- 
 Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-11-24 23:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-22 21:39 Address translation Keir Fraser
2000-11-23  0:49 ` Pavel Machek
2000-11-23 20:23 ` Andreas Bombe
2000-11-23 21:04   ` Bjorn Wesen
2000-11-24 23:28     ` Andreas Bombe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-12 10:47 address translation mani kandan
2005-04-12 12:25 ` Henrik Nordstrom
2003-05-15 11:29 Trevor Woerner
2003-05-15 11:46 ` Gary Thomas
2003-05-16  3:13   ` Trevor Woerner
2003-05-15 12:13 ` Magnus Damm
2003-05-16  3:14   ` Trevor Woerner
2003-05-15 14:05 ` Benjamin Herrenschmidt
2003-05-16  4:02   ` Trevor Woerner
2003-05-16  8:35     ` Geert Uytterhoeven
2003-05-16  9:00     ` Benjamin Herrenschmidt
2003-05-15  3:50 Trevor Woerner
2000-11-21 14:41 Address translation Rubén Gallardo Fructuoso
2000-11-21 17:20 ` Jeff Dike

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=20001125002822.D2324@storm.local \
    --to=andreas.bombe@munich.netsurf.de \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=bjorn@sparta.lu.se \
    --cc=linux-kernel@vger.kernel.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.