[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 18/21] linux-user/aarch64: Signal SEGV_MTEAERR for async t
Re: [PATCH v3 18/21] linux-user/aarch64: Signal SEGV_MTEAERR for async tag check error
Wed, 27 Jan 2021 22:49:43 -1000
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
On 1/22/21 3:59 AM, Peter Maydell wrote:
> On Fri, 15 Jan 2021 at 22:47, Richard Henderson
> <firstname.lastname@example.org> wrote:
>> Signed-off-by: Richard Henderson <email@example.com>
> So when does the real kernel report async MTE exceptions to userspace?
> The commit message would be a good place to briefly describe the
> kernel's strategy and where QEMU differs from it (if anywhere)...
I can add that, sure.
>> case EXCP_INTERRUPT:
>> - /* just indicate that signals should be handled asap */
>> + /* Just indicate that signals should be handled asap. */
>> + check_mte_async_fault(env, &info);
>> case EXCP_UDEF:
>> info.si_signo = TARGET_SIGILL;
> So this doesn't guarantee to check the async-fault status on
> every exit from cpu_exec(), which means we might miss things.
> For instance I think this slightly contrived example would not
> ever take the SEGV:
> STR x0, [x1] # with a bad tag
> l: B l
> because the STR and YIELD go into the same TB, the YIELD causes us
> to leave the TB with EXCP_YIELD, we don't check for an async fault
> in that code path, and then we'll go into the infinite loop and
> have nothing to prompt us to come out and look at the async fault flags.
I'll add that test case to the smoke test.
> Does it work if we just always queue the SEGV on exit from cpu_exec()
> and let the signal handling machinery prioritize if we also pend
> some other signal because this was an EXCP_UDEF or whatever?
> It would be neater if we could keep the fault-check outside the
> switch (trapnr) somehow.
I would think so. I'll try that.
>> +#ifdef CONFIG_USER_ONLY
>> + /*
>> + * Stand in for a timer irq, setting _TIF_MTE_ASYNC_FAULT,
>> + * which then sends a SIGSEGV when the thread is next scheduled.
>> + * This cpu will return to the main loop at the end of the TB,
>> + * which is rather sooner than "normal". But the alternative
>> + * is waiting until the next syscall.
>> + */
>> + qemu_cpu_kick(env_cpu(env));
> This does the right thing, but qemu_cpu_kick() is one of those
> functions that's in a category of "not used much at all in the
> codebase" and which always make me wonder if there's a reason.
> (In particular there's exactly one use in the whole of target/
> right now.) I suppose the case of "helper function wants to cause
> us to leave the TB loop but not to abort the current insn" is
> an unusual one...
Usually something in target/ calls (via mmio or whatnot) something in hw/ which
raises an interrupt, which does the kick.
- Re: [PATCH v3 10/21] linux-user: Fix guest_addr_valid vs reserved_va, (continued)
- [PATCH v3 16/21] linux-user/aarch64: Pass syndrome to EXC_*_ABORT, Richard Henderson, 2021/01/15
- [PATCH v3 14/21] linux-user/aarch64: Implement PROT_MTE, Richard Henderson, 2021/01/15
- [PATCH v3 15/21] target/arm: Split out syndrome.h from internals.h, Richard Henderson, 2021/01/15
- [PATCH v3 19/21] target/arm: Add allocation tag storage for user mode, Richard Henderson, 2021/01/15
- [PATCH v3 18/21] linux-user/aarch64: Signal SEGV_MTEAERR for async tag check error, Richard Henderson, 2021/01/15
- [PATCH v3 20/21] target/arm: Enable MTE for user-only, Richard Henderson, 2021/01/15
- [PATCH v3 21/21] tests/tcg/aarch64: Add mte smoke tests, Richard Henderson, 2021/01/15
- Re: [PATCH v3 00/21] target-arm: Implement ARMv8.5-MemTag, user mode, no-reply, 2021/01/15