David Miller wrote: [Wed Sep 10 2014, 02:50:34PM EDT]
> From: Bob Picco <bpicco@xxxxxxxxxx>
> Date: Wed, 10 Sep 2014 10:30:10 -0400
>
> > In a common part for DTLB/ITLB "BAD RA" check TSTATE_PRIV. Should we not
> > be privileged raise a bus error with SIGBUS and BUS_ADRERR for the task.
>
> The kernel could be accessing userspace via copy_from_user() or one of
> the other asm/uaccess.h accessors.
True and thanx for catching my brain slippage!
>
> So you'll need the full context of the fault to make this decision, just
> like do_sparc64_fault() does.
Yes.
>
> Actually, kernel TLB misses go via separate path and validate the RA
> already before trying to load the entry into the TLB. So you will
> contextually know if we are dealing with a user mapping or not.
>
> You could add a new thread fault code (FAULT_CODE_BAD_RA) to set in
> this situation and then vector to do_sparc64_fault() when this
> happens.
>
> Probably do_sparc64_fault() should just immediately do a
> do_fault_siginfo(). Suggested logic is:
>
> if (!down_read_trylock(&mm->mmap_sem)) {
> ...
> down_read(&mm->mmap_sem);
> }
>
> if (fault_code & FAULT_CODE_BAD_RA)
> goto do_sigbus;
>
> vma = find_vma(mm, address);
>
> I would not try to do anything clever like seeing if this is a
> non-faulting load or anything like that.
Okay let me look at this.
thanx again,
bob
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
