On Wed, 21 Feb 2007, David Miller wrote:
> 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?
SPARC is fine indeed, because it'll never wire the compat code for the
"struct epoll_event" (because an u64 is 8 bytes aligned on both 32 and
64 bit).
Mine was a conceptual issue, where for the only case that would the compat
code for "struct epoll_event" cover (u64 align 4 bytes on 32 bit, and 8
bytes on 64 bit), we are using {get,put}_user on an unaligned (4 bytes
aligned) u64.
If all the architectures that require "struct epoll_event" compat,
guarantee that a {get,put}_user of a u64 on unaligned memory works as
expected, then Stephen code is fine.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
