Re: [PATCH v13 00/12] support "task_isolation" mode
From: Andy Lutomirski
Date: Mon Jul 18 2016 - 18:12:23 EST
On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf <cmetcalf@xxxxxxxxxxxx> wrote:
> On 7/14/2016 5:03 PM, Andy Lutomirski wrote:
>> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf <cmetcalf@xxxxxxxxxxxx>
>>> Here is a respin of the task-isolation patch set. This primarily
>>> reflects feedback from Frederic and Peter Z.
>> I still think this is the wrong approach, at least at this point. The
>> first step should be to instrument things if necessary and fix the
>> obvious cases where the kernel gets entered asynchronously.
> Note, however, that the task_isolation_debug mode is a very convenient
> way of discovering what is going on when things do go wrong for task
>> Only once
>> there's a credible reason to believe it can work well should any form
>> of strictness be applied.
> I'm not sure what criteria you need for this, though. Certainly we've been
> shipping our version of task isolation to customers since 2008, and there
> are quite a few customer applications in production that are working well.
> I'd argue that's a credible reason.
>> As an example, enough vmalloc/vfree activity will eventually cause
>> flush_tlb_kernel_range to be called and *boom*, there goes your shiny
>> production dataplane application.
> Well, that's actually a refinement that I did not inflict on this patch
Submit it separately, perhaps?
The "kill the process if it goofs" think while there are known goofs
in the kernel, apparently with patches written but unsent, seems