Re: [PATCH]add epoll compat code to fsl/compat.c

[David Miller <davem@davemloft.net>]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 21 Feb 2007 13:15:58 -0800 (PST)

> On Wed, 21 Feb 2007, Davide Libenzi wrote:
> > > 
> > > We can't trust user pointers, and that includes not trusting them being 
> > > aligned. 
> > 
> > Don't we get EFAULT in case of exception (access or alignment) in there?
> > For "dealing with", here we'd need them to do the correct thing 
> > (split-load?) in case of mis-aligned access.
> 
> I sure hope no architecture does that. EFAULT should be for *unmapped* 
> accesses, not from users just using unaligned pointers. 
> 
> I would argue that it is a bug if some architecture thinks that 
> "get_user()" and "put_user()" don't do unaligned accesses. 
> 
> (Not to say that it might not be something some odd architecture *does*, 
> but I'd be disappointed if somebody did)

If unaligned accesses in userspace give SIGBUS, which is the case
on both Sparc ports, it is a question of whether the same should be
done in cases like this.

I can definitely see arguments in both directions.

On the one hand, if userland has the have aligned stuff while he
executes, he should provide the same for things he gives to the
kernel.

On the other hand, userland has no way to embed structures passed into
system calls, using things like the "packed" GCC attribute, and
communicate that to the kernel.  So in that regard, the kernel should
try to handle the unaligned access as best as possible.

But currently we -EFAULT on sparc in this situation and I've never
seen a problem because of that.

Nevertheless, I am to understand that in this case we're talking about
a "u64" object, and that (and the structure it is in) will be aligned
on an 8-byte boundary on both sparc32 and sparc64, so maybe there is
no problem here?