lkml.org 
[lkml]   [2015]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode
From
Date
On 09/29/2015 01:46 PM, Andy Lutomirski wrote:
> On Tue, Sep 29, 2015 at 10:35 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> Well, the most interesting category is things that don't actually
>> trigger a signal (e.g. minor page fault) since those are things that
>> cause significant issues with task isolation processes
>> (kernel-induced jitter) but aren't otherwise user-visible,
>> much like an undiscovered syscall in a third-party library
>> can cause unexpected jitter.
> Would it make sense to exempt the exceptions that result in signals?
> After all, those are detectable even without your patches. Going
> through all of the exception types:
>
> divide_error, overflow, invalid_op, coprocessor_segment_overrun,
> invalid_TSS, segment_not_present, stack_segment, alignment_check:
> these all send signals anyway.
>
> double_fault is fatal.
>
> bounds: MPX faults can be silently fixed up, and those will need
> notification. (Or user code should know not to do that, since it
> requires an explicit opt in, and user code can flip it back off to get
> the signals.)
>
> general_protection: always signals except in vm86 mode.
>
> int3: silently fixed if uprobes are in use, but I don't think
> isolation cares about that. Otherwise signals.
>
> debug: The perf hw_breakpoint can result in silent fixups, but those
> require explicit opt-in from the admin. Otherwise, unless there's a
> bug or a debugger, the user will get a signal. (As a practical
> matter, the only interesting case is the undocumented ICEBP
> instruction.)
>
> math_error, simd_coprocessor_error: Sends a signal.
>
> spurious_interrupt_bug: Irrelevant on any modern CPU AFAIK. We should
> just WARN if this hits.
>
> device_not_available: If you're using isolation without an FPU, you
> have bigger problems.
>
> page_fault: Needs notification.
>
> NMI, MCE: arguably these should *not* notify or at least not fatally.
>
> So maybe a better approach would be to explicitly notify for the
> relevant entries: IRQs, non-signalling page faults, and non-signalling
> MPX fixups. Other arches would have their own lists, but they're
> probably also short except for emulated instructions.

IRQs should get notified via the task_isolation_debug boot flag;
the intent is that they should never get delivered to nohz_full
cores anyway, so we produce a console backtrace if the boot
flag is enabled. This isn't tied to having a task running with
TASK_ISOLATION enabled, since it just shouldn't ever happen.

Thanks for reviewing the possible exception sources on x86,
which I'm less familiar with than tile. Non-signalling page faults
and MPX fixups sounds exactly right - and I didn't know about
MPX before your email (other than the userspace side of
the notion of bounds registers), so thanks for the pointer.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com



\
 
 \ /
  Last update: 2015-09-29 20:21    [W:0.378 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site