From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756964AbbJAT0n (ORCPT ); Thu, 1 Oct 2015 15:26:43 -0400 Received: from mail-am1on0098.outbound.protection.outlook.com ([157.56.112.98]:36291 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933123AbbJAT0Y (ORCPT ); Thu, 1 Oct 2015 15:26:24 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode To: Andy Lutomirski References: <1443453446-7827-1-git-send-email-cmetcalf@ezchip.com> <1443453446-7827-4-git-send-email-cmetcalf@ezchip.com> <5609B713.5020709@ezchip.com> <560ACBD9.90909@ezchip.com> <560AD0F5.6080000@ezchip.com> CC: Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , "Rik van Riel" , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , "linux-doc@vger.kernel.org" , Linux API , "linux-kernel@vger.kernel.org" From: Chris Metcalf Message-ID: <560D88C5.7030000@ezchip.com> Date: Thu, 1 Oct 2015 15:25:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: CY1PR1001CA0030.namprd10.prod.outlook.com (25.163.136.40) To DB5PR02MB0773.eurprd02.prod.outlook.com (25.161.243.144) X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0773;2:PG88Uxr+gptTLuhSD1L9i7ronboO6mPlGBSqqMfp179LviPmEDGx6lf8lt6B5qQtBnILQPUOhBgZJlQSBsEb7nf1Mxa4JsFn7Ta/TxTiI6FHxOGkn9vlpKUNc5RILj2vRTeg7qf3YZhRkRNRTrv+GcmicenTvsvQt9dVPKM2Gn8=;3:UWDnlgrOL7T09TnEeaEb/Qyb9oDf7T4NlQWrnDHwDBd4OoO7BewT/CJd5nzLXDqt2Thneclq8+HpAXzargSDTwaZl/MuXEHkrK2xuviLjFJfD6zJqftj2zvwbUbT9f45OhJcGNTxnEOPYh8rblNDzA==;25:0eS3wA/JoeOlt7thk2kiJnjP+tiaz/qaNX6aOZImS6Wsk//F/0NKl1qcZ7msr8PI49bYYTB5duolRUSf7BS2w4wRTw2wXFhGMw+/VOyzCQ9CwAOcAwLsOch+V7bDpLw4JbiEdjYyl9o3Z7up8GXjaFx+y4Jp/2OsbGRHhd1WcTOU2hkJkM52lsOBa408hBXOzSWm70PGHVL67yGxnl6rkBW8NaVcCVi3yAIF3Nt4T1D+We2bcYYWoz4vwrekYYuwcOxc4+eJmyiyBHmSbx2JTg==;20:37xp4B7KjNGMxODZiLn8ckRtUKbpoy8Vq7J16K61hAXNt1b9zz++ZsHOJH6GjhNEOvVMkNQ1R9g0AlVGCDzGFG0HdZGr9e5JLt9G2iCGz4Cc/J8uWbdBGfkKa8ra9AqPlP7lwXB8Mx7SdCOAx+plUADCKNbM/seogigmkJMr57k= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0773; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001);SRVR:DB5PR02MB0773;BCL:0;PCL:0;RULEID:;SRVR:DB5PR02MB0773; X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0773;4:3vRDZ/r1Emkvt1eBT3OLpXCfTE8RtIqq4iQ0CUOfDMJqH4Q5b0q84ZcLKInO6X3hpHjkrTjvXnkOO7UngPRF+F3Dh4G0M0+e9JpEf8wE7eZU8mdWIFJeD5DA8sSaFtLI944htseaUsC4uklUBU3+t8nKOgvig2FxIqaPStaBr8LZWeiCwFaW4NSf2QJ+lbT0jWRz95dxVma93Pgoq61kVQvePr43treXhl9vopDcueLHOvaYCCQMD9vUFgIbjDCwM0Ve3Vzr0dvPJVi6EndJTPo6pOgiGs2xoa2LDJjptEvSpMLy50+946u7+vTsOU/Y0OEGnL4RJIqxj6NuAcopAf5IBDnltQ6W1AEe3OrkgpY= X-Forefront-PRVS: 0716E70AB6 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6049001)(52314003)(479174004)(24454002)(377454003)(199003)(189002)(40100003)(97736004)(65816999)(46102003)(47776003)(81156007)(19580405001)(59896002)(5001830100001)(4001350100001)(50466002)(101416001)(93886004)(2950100001)(23676002)(80316001)(86362001)(5001860100001)(105586002)(33656002)(62966003)(106356001)(77156002)(5001920100001)(36756003)(76176999)(64126003)(66066001)(50986999)(110136002)(92566002)(189998001)(83506001)(54356999)(122386002)(5001960100002)(87976001)(65956001)(4001540100001)(42186005)(87266999)(19580395003)(15975445007)(5008740100001)(77096005)(5007970100001)(68736005)(65806001)(64706001)(5004730100002)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR02MB0773;H:[10.7.0.41];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjAyTUIwNzczOzIzOjVrZVArbVVDbkgrdE9PRkVDdEluM2xGNHN2?= =?utf-8?B?NzE0d055eCtneWZhV2dmVFY3UHVEUjZMZXY3RDRFTjQ4MFNKMEtJWFQrNXBU?= =?utf-8?B?VTB2bGhBM3ZheDJwTFFlTUFjbzdib2psSldVYWprYXZHUndOMEJOV2h0VzdU?= =?utf-8?B?aW9kbGlWMjM0bWtTajRacDRITk1FQnVkbG56aitidEFFb0xDZTNneXdGb2dw?= =?utf-8?B?dU0yUlVMaGI0MTdKajI2a1VjYXRNQmR2ZFpJNjhqVWkwaGE1dlhoQXVYZlV4?= =?utf-8?B?bzhkb2VmMURzS1VzdTRaZzZ6alpxeDJLSUJ3eUdlMTZvTGcyWFlRZUhKODNk?= =?utf-8?B?Y2hCOTFGMnhET0V1Q29jZUZMWDdUVjVBSzNrYmNZc2VUK29LTEZhTThpV09k?= =?utf-8?B?TW1qdGU0THY3YVp5ODYrcEY0d0U4aDhoS09uSXZvZ3p0Q3lzd3cxbXNpOHNo?= =?utf-8?B?elFTK3RLQlJOZEh6NTY5eHRGSDlNTlB1WVppYXNXc09DNmlTQTBUTmJEVG1n?= =?utf-8?B?cWZRZ2xOZTIwWVJUNTJaRjdIb2NsSGNVR2UzaGRRdVl3cDBZY2tUYXVUNFk1?= =?utf-8?B?czlFUGZnUUdKMGNEdXoyQWpEWFBlcFVibHRYWjRvU0pWMDNISUpEdkx6TTY0?= =?utf-8?B?VGFQZk96RUdEdXR1M0w4WkpBK3plVlUxMUhwVFg1K1R0TTNoVytuck9ldTB6?= =?utf-8?B?OG5BMTVhSzhzazI1bUVRdGpnTzFnMm1TQWlWUGRXcHpGdW8ybUY1c1ZSeGlO?= =?utf-8?B?Q3lkVTNtc2kyMjF4Z1hkUGNKOUZBOWdQK2p2L3VaZjRLQWZGL0VaY0hwQ1dz?= =?utf-8?B?M0FEK2pLL3NSZ3dERlVEb0g1dzU1ZUxiVmwwT3BZc1ViS3YrRzRTQWFqNVZl?= =?utf-8?B?KzRrVFlDUFhORTNzYjJuY3dQWVdjN1pzUk9uM2p6VGh5TnBKQkd0RGxuUG1V?= =?utf-8?B?d3VpQTRkZ3B0eWRrdm1KU25aaTl3QXhlTklZOU1xQWtBVjNUS1FFaktiTEZC?= =?utf-8?B?VDJtMGNQbGQ5eFcrQmoyUnY0OEhKUWJWMENJaFc3cDNJMXdJYWFPaGpKMzAy?= =?utf-8?B?NFg2THZBbTR2Mm0xUnU2MG1PdVZDS01GUjVYd3c4dEwvV3Y5am1TMmxtbC9p?= =?utf-8?B?R25vM2ZLblhPQlRCRjdRZHVoSUg1a2xaM0ZqODEzN1FmWFlORVpid1NZaWJQ?= =?utf-8?B?MVJURTI0djlEWkliM25OWlhMUjRzSGJmWDh1dFJ5V1U4L0duTkFVbE0xemJE?= =?utf-8?B?c1QvWktXRHh0QTUxbm1IV0w5OHdMWmdLR1V0SGZtY2YzT2xOQ0RFSXdGTHdt?= =?utf-8?B?dU5Qd1AwbkZ1cmx2bzVGd1ZhaWROVTVqZ2pOOExxckdTMzVsQzJqWFF4em5a?= =?utf-8?B?MS94NmdDUU9TcHE3eDMvdzRkOUlmY3k0d1Q4Zk9PKzhtUDJucjY2Z1pVTjhG?= =?utf-8?B?ZjlCT2NGdWZzWGF1UE1ZTC9qK2JkSzZWQzFRRXVHazBWTWlac09XR09XL1g3?= =?utf-8?B?aFkzelZ1am40U0x0UTFsNGsrcitUSWZiSnhBR3I1NUVLUTcvWHltdkE5cXds?= =?utf-8?B?aGZQWmQya3FxbHRjdHFrdlRSUHJsSjJQMTQzZVRRaHU2eDBPYUJ2M25ZT2o5?= =?utf-8?B?M0tscm5rTkI2MlN2YWJJdmgxTEFsaXViTnpMNW9ZaEh3YklzYWRjSURva2wv?= =?utf-8?B?aVRVTnhpQm1OZEJNaGFzaS90Z0srRU5XN1hJdmRRMHdyYnlCRXcxampiWU9q?= =?utf-8?B?TDVsYUc4aXNzVkViUGJ2NUVxNWxyc1lndDFEYXpUVWVxRUliRklqbXZKNE10?= =?utf-8?B?TTI4S0YzYW9YZjF2YmNnNjFOMFFHTlIrVm51dWkxYmNub0hYclZZL3lpRTlN?= =?utf-8?B?b1hEd05jYjVsQVk3Nnozby9QZGRUNjJjQVJXb0ZaQlJSQmlBeHdPcCtEd2lS?= =?utf-8?B?anpyclZaMnJHSXdwMzVYSE9SUitVd0d6MlIvcnFZWWpiOWlsWVUvaUxhNmd4?= =?utf-8?B?WGx1NTEwaTNlNEpMWVQzMDNrQnNTTlZtUEdQWGZCckwyb29MNFNnV08waDl2?= =?utf-8?B?WmFvNEhLZkxjQWlYWVlIVEpubW9hRjkwWWlPY2tMcVBkLzFCS3AyLzJxeWEz?= =?utf-8?B?SVE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB0773;5:0LBk8fHjCfJ0KUragrV+xwxbhBOXJRLQ/qfoL7MSctu/f7d1n+/rx3l8aOww676zu5f1sURKuvYgaz2Dv0qeUbA72jLbeUJELjJLhpujmceNX137a4wJ4Rf5r7KtqTgFyZ/h2L2smvbIKKISNdoAIQ==;24:bXvoq2bQAEbV3UIPaPzJeFEBS+/XibzpZbFajerRiP90svtyMNWLXfwLKP5+fYyx6ui+LTXzSr8UPVjJUGNqs7/VQeJeitXerOO44De9k28=;20:gr1toKVTG2ZN8B1hJhqnow22V36L1CjAwrfYFQAq41Mv86Hkxk0R77m7YAJo7CeI7QQlJzTpxA0XwUcQ0WpWxQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2015 19:26:16.6972 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR02MB0773 X-Microsoft-Exchange-Diagnostics: 1;DB5PR02MB1240;2:z8Olx6r9U+6LVy7ITeQKki6ZBItpNmUjP2IpRLkHavnkfelYPAnDm4MwaZ/8fC3L7STYHLC3NZgJKuIGPKQgCv3GXqLzKcjTlq+bTw4l/y+3nsBPS340xmykXtr2mOd58ANMb/VEwcKH5yRO48GaVLZtuLxHnl1qyVGkiXsv5GQ=;23:IArQi0Q/dJTi7yPLeyP+b/GtzUlEyJeNGSYgN8wDX1wJ7eHpm+UgNQO8ZMhVhVswboMdMptBtIu83+e9LStRa0/bxcUBu7PFUSDDX2WZGbMAuyD30RXxisuC0Xc8OvAjWEvVxRGO2zJEzwf7G91XYcIDVB+1QIumsl+3uf2u6mdlUtPwPGbbTLjkVP5+t+sQ X-OriginatorOrg: ezchip.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/29/2015 02:00 PM, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 10:57 AM, Chris Metcalf wrote: >> On 09/29/2015 01:46 PM, Andy Lutomirski wrote: >>> On Tue, Sep 29, 2015 at 10:35 AM, Chris Metcalf >>> 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