public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: monstr@monstr.eu,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	LTP <ltp-list@lists.sourceforge.net>
Subject: Re: access_ok macor
Date: Wed, 15 Jul 2009 18:21:13 +0900	[thread overview]
Message-ID: <20090715092113.GA1863@linux-sh.org> (raw)
In-Reply-To: <200907141913.21240.arnd@arndb.de>

On Tue, Jul 14, 2009 at 07:13:20PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 July 2009, Michal Simek wrote:
> > when the code tried to read/write from unaligned address (and in cpu
> > is turn on unaligned exception) then is caused unaligned exception
> > and asm code assemble/return value which is on that unaligned
> > address. (Assemble it that read/write every byte separately). That
> > will be harder to prevent all this cases because unaligned exception
> > is in generic code.  What do you mean add __range_ok? Range checking
> > is ok. The problem is when in case get_user kernel try to load
> > unaligned addr - unaligned exception is perform and try to load that
> > value separately.  If that page is not there, page fault handler is
> > called and not find it, it is performed search from exception table
> > and that address is not there of course - because address in pc is
> > generic unaligned code. I think that handling this needs more code.
> > Maybe if the address with from unaligned exception handler (there are
> > some address which can caused it) and find out which aligned address
> > is there and find out proper fixup for it.  I think that this could
> > work.
> > 
> > What do you think?
> 
> I think the key point is that the kernel should never try an unaligned
> access. Other architectures already rely on this, so you can too.

No, other architectures used to rely on this, until it was no longer
possible to do so. See for example, nfs. Unaligned accesses by the kernel
must be handled by the architecture, unaligned accesses by userspace can
be optionally fixed up.

  parent reply	other threads:[~2009-07-15  9:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14 12:56 access_ok macor Michal Simek
2009-07-14 13:21 ` Arnd Bergmann
2009-07-14 13:45   ` Michal Simek
2009-07-14 14:45     ` Arnd Bergmann
2009-07-14 15:06       ` Michal Simek
     [not found] ` <200907141652.59049.arnd@arndb.de>
     [not found]   ` <4A5CAEFF.9080206@monstr.eu>
2009-07-14 16:43     ` Arnd Bergmann
2009-07-14 16:56       ` Michal Simek
2009-07-14 17:13         ` Arnd Bergmann
2009-07-14 17:45           ` Michal Simek
2009-07-15  9:21           ` Paul Mundt [this message]
2009-07-15 10:03             ` Michal Simek
     [not found]       ` <9e6f3dfd0907141811p512b4edp3f9dd0fdeae1123e@mail.gmail.com>
2009-07-15 10:14         ` Arnd Bergmann
2009-07-15 11:39           ` Michal Simek
2009-07-15 12:05           ` Ralf Baechle
2009-07-15 13:27             ` Arnd Bergmann

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=20090715092113.GA1863@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=monstr@monstr.eu \
    /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