Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Thu, Nov 23, 2000 at 04:50:26PM +0000, David Howells wrote:
> > user code to emulate unaligned accesses, which can be written as someone
> > actually found a userspace programs that needs them.
> 
> We have the code anyway to fix up kernel accesses.

no.  we have the code for the few insns actually used by the kernel, and it
can go away as soon as someone convinced DaveM having the network stack use
unaligned accesses is silly.

> > I think you're wrong.  there are many insns the kernel doesn't use (which
> > your patch doesn't emulate either), and the kernel version needs to validate
> > every pointer it dereferences.
> 
> All the instructions emulated in my patch can be produced by gcc (there aren't
> that many really, it's just that delay slots complicate matters). The multiply

yes, but they're not all the instructions gcc generates.

> from memory is admittedly one I don't emulate, but I don't think that's likely
> to occur - but I could be wrong.

Do it correctly or don't do it at all.  "We emulate all unaligned memory
accesses except 3 or 4 we didn't bother with" isn't a sensible rule.

> Furthermore, the hard part of pointer validation is handled by the MMU, and so

True for userspace emulation as well.

> incurs minimal penalty. The unfortunate part is that gcc can't handle two
> different exits from an asm statement, and so it can't be made to goto a label
> somewhere else in the function upon faulting.

indeed.  __label__ a;  asm volatile("bra %0" : : "l" (a));  a: would be cool.

> > It never passes it back to userspace.  it generates a segv for userspace.
> > it is a system call return value, and there is no system call directly
> > involved here.
> 
> Indeed... it's entirely internal

which makes using a syscall return value constant confusing.

> > use "1".  use SIGSEGV directly.  use any other random value as long as it
> > makes sense as a constant.  EFAULT doesn't.
> 
> Actually, EFAULT just means "Bad Address" doesn't it?

In the context of system calls, yes.

> > > > It just means your comment is wrong.
> > 			/* Argh. Fault on the instruction itself.
> > 			   This should never happen non-SMP
> > 			*/
> > 
> > > No... The comment says that the "if" fires if the attempt to read the
> > 
> > Yes.  It can happen on UP systems.
> 
> No, I don't think it should. I discussed it with David Woodhouse who actually
> wrote the comment, and he pointed out that the only reason we should ever
> fault there is if on an SMP system, another CPU unmapped the page at an

which isn't true.  see my earlier mail.
<
> inconvenient time. If the page wasn't there in the first place, then we'll not
> come in through do_address_error() since there wasn't an unaligned access (as
> the CPU won't have been able to read the instruction to see if it was an
> unaligned access).

address error doesn't necessarily mean unaligned access.