lkml.org 
[lkml]   [2015]   [Oct]   [1]   [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 02:00 PM, Andy Lutomirski wrote:
> On Tue, Sep 29, 2015 at 10:57 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> 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.
> OK, I like that. In that case, maybe NMI and MCE should be in a
> similar category. (IOW if a non-fatal MCE happens and the debug param
> is set, we could warn, assuming that anyone is willing to write the
> code. Doing printk from MCE is not entirely trivial, although it's
> less bad in recent kernels.)

For now I will stay away from tampering with the NMI/MCE
handlers, though if it turns out that it's the cause of mysterious
latencies in task-isolation applications in the future, it will
likely make sense to add some debugging there.

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



\
 
 \ /
  Last update: 2015-10-01 21:41    [W:0.131 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site