From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@ozlabs.org
Cc: prodyut hazarika <prodyuth@gmail.com>
Subject: Re: Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
Date: Fri, 11 Jul 2008 09:02:43 +0200 [thread overview]
Message-ID: <200807110902.44237.arnd@arndb.de> (raw)
In-Reply-To: <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com>
On Friday 11 July 2008, prodyut hazarika wrote:
> I have a version which just keeps a count of bytes copied till any
> fault happened. Then for any exception, I just substract this value
> from the total number of bytes to be copied, and store in r3 and
> return back. This is the common fixup code for all paths. It makes the
> fixup code much more readable like other architectures (eg. x86).
In some cases, you need to make sure that the return value is exactly
the maximum you could copy, not a little less.
> The current code tries to copy one byte at a time after read fault. I
> don't understand why that is necessary. It then clears out the
> destination. All these logic has made the code very unfriendly to
> read.
I'm not sure if the code is also avoiding unaligned accesses here,
which is not a problem on x86. If you access uncached memory with
unaligned pointers, you get an exception and the fixup code will
copy it just fine with byte accesses.
> 2) For read failure, why do we clear out the destination (lines 509 to
> 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that.
All architectures should do that for copy_from_user, to avoid potential
data leaks from the kernel when the data is copied back.
Arnd <><
next prev parent reply other threads:[~2008-07-11 7:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 23:44 Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S) prodyut hazarika
2008-07-11 6:50 ` Michael Neuling
2008-07-11 7:02 ` Arnd Bergmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-07-10 18:06 prodyut hazarika
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=200807110902.44237.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=prodyuth@gmail.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 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.