From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753970AbbI1V4E (ORCPT ); Mon, 28 Sep 2015 17:56:04 -0400 Received: from mail-db3on0099.outbound.protection.outlook.com ([157.55.234.99]:34256 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752623AbbI1Vz7 (ORCPT ); Mon, 28 Sep 2015 17:55:59 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@ezchip.com; Subject: Re: [PATCH v7 05/11] task_isolation: add debug boot flag To: Andy Lutomirski References: <1443453446-7827-1-git-send-email-cmetcalf@ezchip.com> <1443453446-7827-6-git-send-email-cmetcalf@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-kernel@vger.kernel.org" From: Chris Metcalf Message-ID: <5609B75B.9040204@ezchip.com> Date: Mon, 28 Sep 2015 17:55:39 -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: CY1PR21CA0089.namprd21.prod.outlook.com (25.164.213.15) To AM2PR02MB0772.eurprd02.prod.outlook.com (25.163.146.16) X-Microsoft-Exchange-Diagnostics: 1;AM2PR02MB0772;2:l7x50IpnZWwmh7aevnKVnNaMI4E4ltvUaBOPWRoLX1aNoKbF88spbQBwnqqxXakEtP5UcGXLI+FVowcxPzWwbywVxjBHgN/UhMRjmjkmXJKr9E27Uy9ntxvJfxvDyIcIaJg5/5aQseP1Os0yTbIDGrgTJAj5b5+i4puT+RO2D6I=;3:MmdRdJAjxPtI/zDwiQ04A6J6iAo4+yuFFHhjQpo2Np1oybmAdaSE0yWPNsSm6qYzQb0I9V63M4M7vLpsyXhqNICx0wK+vUnEl26oF1gyYvbvoGvzkAsohmKMaHVxdM+bdkNCe1zy+mj69b8quuSv4Q==;25:U4LVsPUGRp8C53QVmuxEWFuBy6wQxYjgxbyvEn8n5bsAbvYZsGcg6536hs2orOxQhGOH9G/wCGT9upm4T7mjdQZJ3zLvk8wOI5z8m2uKTY3swtVgnh8I/ZiF0qqY08iPRekyWcvg23umvwUR17586MRwz5srOqKE+uCA3aNEg0Zv3fR+sYAMSdxJHuXUFHF6mKQJelbmunn4JlsW9Zz8OlHX8FLDzJvq3tJtLcqCkKtH4atHg2LEqQHy/iO/1rLw5sCBXL8H1e17/cPoSKBMnQ==;20:pnHOhNsi6hkcclNIIrXv0KihBJW0Aom6MqLsLC5BBW14n4OdU4U2JMBI/HcXQf4I2M+0JVNWUDHWhby2q55YqRA0c5krYxFyEqWYnB55dxXj9wUQz79ZoepP0OcLP4wnR9NzZDkiA+xMkF2jiFHVKxTVo58zI67hc+Ys4JKwWa8= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR02MB0772; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001);SRVR:AM2PR02MB0772;BCL:0;PCL:0;RULEID:;SRVR:AM2PR02MB0772; X-Microsoft-Exchange-Diagnostics: 1;AM2PR02MB0772;4:jVLFXzqG8iYC4V++DPzK+bepBXsqPJprP3Z/Hv3yxL/4Vhl+9/eKMcwbmJ18BNLtzOqG1fB/BYUJ9ErjNVmPHdftkiyGiVTxmTmnDJdN200vNlKcBU9vVxJ7fVEGIpFKvjPpy2lkGG7eU0lWGz91N8ue+i/ccBlRgYoqnChkRtolFmUf1T5EA7O9GeC/bxMV/bPDSdCA3njLvY25JuyKZ9kIsyKPDcJEz17DrRXiP8Kl6GAR4u6ybZO69TTooUTuSX6i94eewazd60B+qgL8AJtw2PB+orGCDgOSENX9TuTZVYXPr1kDP73FcOhdqbGl9u7wj3BlxL/yH/XeHpoxsgzfipqgzHjkpLc4REMrG+I= X-Forefront-PRVS: 0713BC207F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6049001)(199003)(24454002)(479174004)(377454003)(189002)(50466002)(189998001)(76176999)(5004730100002)(87266999)(105586002)(50986999)(5001960100002)(40100003)(68736005)(110136002)(4001350100001)(80316001)(19580405001)(5001860100001)(46102003)(23676002)(81156007)(97736004)(4001540100001)(5001830100001)(19580395003)(122386002)(54356999)(2950100001)(5007970100001)(77096005)(36756003)(77156002)(15975445007)(106356001)(62966003)(65956001)(64126003)(92566002)(65806001)(66066001)(64706001)(47776003)(83506001)(59896002)(65816999)(101416001)(33656002)(42186005)(86362001)(87976001)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:AM2PR02MB0772;H:[10.7.0.41];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTJQUjAyTUIwNzcyOzIzOk8ra3lXeWxwU0N6WWl6SmJRVUpSMllYQ3ph?= =?utf-8?B?dFhMalRTaHZvMEVMSm1Db0R6dklaYXlleVZBZ3lzN3l6TXQvTUUxbDYrNjhl?= =?utf-8?B?c2xNbld4QWhBYVYxWVhKdWhGR0NCbmhxS1AyTGtWYXRVbzFhRVZzdm9oZVhz?= =?utf-8?B?SGwzdEVoUnpMV3MySmR5Tm9OWFZHZGFiK0hvQXBmK2xCa0Vkbm1Eb3REVG5o?= =?utf-8?B?dHY5WW16c0h1SUhEUkRoZjFNMDhUUURIM3FrME41WG9WOWRtTDE2OEd4RTdp?= =?utf-8?B?ZmRNM1M2dC9UcGRVQkYzUWhrVFR2SmF2SXYxQWdIdGRyZGZJaUdCSngwMVpH?= =?utf-8?B?UEkyUWNvYUN2dmZoVjludUZtbnVMa2dLenNVRHJJOUZtdXlMR0lmNGUzQjFU?= =?utf-8?B?MTQzUzVhV1BmZzZsVThmcHdnajg4UUZoTHpybXZLdjczdXF0ejk5ZmwzUzJp?= =?utf-8?B?d3kyUlltaVFFQzlaMStjK0hlYTlYRnBwUXBCQzBJZFc2SFZsa21pY3VFL3g0?= =?utf-8?B?dVBZazRrZmVKdWZ1WHVNUjJMalZBVURQa051RkQwenVUa1VYbDE4UCtneTJw?= =?utf-8?B?S285YUJWdGMyanIxdWhjQUV0VjZOTnBLMUFpeUdsMzkyYWVUckhUbkthNjlO?= =?utf-8?B?WndlZnlNNnlUV0xidUgrZGlDTUJZdGNQMjZSUDZ0RUpwTEFvZUdVOVNFYU9Z?= =?utf-8?B?dC9ZTmIrSWNRcUpmWnkrUCtVSUlJcTlhRkp1bmxDcXZMZVlmSWdmOWx3blNv?= =?utf-8?B?dVlYMnJGTjg2c1dvS0hMZUlmbHA4Kzg2YW92dGl5SngwaHpUZ1h6Z1JxVlhx?= =?utf-8?B?ZG9ubXZueXdGUm5FMW1tZWpsaHdyWk5sZXZER092aGZmLzA3VFpzbUpTK3dW?= =?utf-8?B?VHNEQ1MrYjZ6RGlqVTExZ202UXhKMzF6d256TUJkME9pNnNoNUF2OGV2SkpI?= =?utf-8?B?dTZnck1YcmVyK0NEVXFWdXB3eWlSQzBWbllDaWRKVEU2YVphZjd5MnZsaXRC?= =?utf-8?B?N0ZxbHA4bmREYkY3YVFuMGl5cGY5bUlCNEFzTTRpMlhQckVpUkozanBzaFFO?= =?utf-8?B?eGFzNUFxZmw5c3VVTnRjTGdnanNlSkRnNnRwT0ZMMjY0YVp2SmF6SkhXeTdT?= =?utf-8?B?R3dCQkhReDN3Q0hobkxpbVlLNnp3ZXA2N1FkZFZSYUswWEpGaW40d1hVdUxU?= =?utf-8?B?RmluaGtGRTZBYjdHZ0xmUE5EUlF1bmRaNXZpWWY4VTVVazlqekJrcjhEK1FL?= =?utf-8?B?WGgxcENJYlo0UWdOZnB0Nk1pYU5QT0RGRUM3NmVLSGRSeVI0K0tqSjQvQlpi?= =?utf-8?B?bHY3NGtrWWRTc1oyOUhrTFB5WHNLbVVackc4NlJYWERFTHR0dFh2b2xzVFpJ?= =?utf-8?B?ejZDeTNHSk1PUVY1Qi9SYU1wVEdKZzJlcUxoOVdZN3ZXdkVvK2ZzbFFaeGpr?= =?utf-8?B?OUZHSExZRnYwZHQ3T3BVemJjWGZyTHBrOGVyTTU2aHZpVTZZQU1wWHhwbmgz?= =?utf-8?B?VEJhSlBubGt5amtwUlJwYUZmcTBQMEYrbjZTdmo0YTFiSno4Vlg4MlEvQlVE?= =?utf-8?B?RC83S0hnUkc1U0dBVEVtcG81RXU0ZkdIUXE3eW5BOXIyL2xMM2o4SSt6b1oy?= =?utf-8?B?WW4vSjZhR3FMdEhyMzBodXVFQjgzcTArMXV6UkpoY0QxaDBVMEJuTllkKzdk?= =?utf-8?B?SjFMMzZSNVlyZkUvZ2NyTStTQW9FbmtlUS9Bay9DRUV4bkQwR2lFM1EyZFc1?= =?utf-8?B?L3BvM0hYeWYxcWlMeEdXL3ZORHpaalJjMmsxK1VTeHlsNy9OdXJrcC9FcS81?= =?utf-8?B?RjVXdEdKeTJOV0ZCcUtMUzBuQVJzNEJrVUF2OXQ3NDROWG9wL0doNERVKzZh?= =?utf-8?B?U2JCbXA0V2I0YUVVbjY1VVZZdGw0dmEwYm1zcVRlQmJkeTNoMnBiMDJmY1JJ?= =?utf-8?Q?esEuZlEtlIim9TPasKglqSdFLbcmpM=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM2PR02MB0772;5:WVuq0j01twseMdM+PjyVnONmOm1IUIu+Ds2GIeN8IYyw0fdzGx01alZ/KMIYPSN6UxqDBiNXta0Gi0OvUpZ6Zu086kuB5MaXPEUyl0ZeO/jFWbU0Q+tZ1IJL4D8SIzbwD05S4MGP2M5QO0YybaK34g==;24:lNTdBb2/teU/85RjGNsCQ533n8+hmauQWzb+B6N5VDOmmKIwQCSusYKYQHEVF8NKf83Z0x0Q3MkWcH7xRyPpdKYj91Bjj7UZt65o2wH9hIA=;20:bsr5jfyr1yAmfmcd+P2vlYJmBQUqkhHJOd03z2Y4ajyL2dRIsW96uXl6+t+hB7x3/szpapKXVIngctR0PHYIvg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2015 21:55:53.1783 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR02MB0772 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/28/2015 04:59 PM, Andy Lutomirski wrote: > On Mon, Sep 28, 2015 at 11:17 AM, Chris Metcalf wrote: >> The new "task_isolation_debug" flag simplifies debugging >> of TASK_ISOLATION kernels when processes are running in >> PR_TASK_ISOLATION_ENABLE mode. Such processes should get no >> interrupts from the kernel, and if they do, when this boot flag is >> specified a kernel stack dump on the console is generated. >> >> It's possible to use ftrace to simply detect whether a task_isolation >> core has unexpectedly entered the kernel. But what this boot flag >> does is allow the kernel to provide better diagnostics, e.g. by >> reporting in the IPI-generating code what remote core and context >> is preparing to deliver an interrupt to a task_isolation core. >> >> It may be worth considering other ways to generate useful debugging >> output rather than console spew, but for now that is simple and direct. > This may be addressed elsewhere, but is there anything that alerts the > task or the admin if it's PR_TASK_ISOLATION_ENABLE and *not* on a > nohz_full core? No, and I've thought about it without coming up with a great solution. We could certainly fail the initial prctl() if the caller was not on a nohz_full core. But this seems a little asymmetric since the task could be on such a core at prctl() time, and then do a sched_setaffinity() later to a non-nohz-full core. Would we want to fail that call? Seems heavy-handed. Or we could then clear the task-isolation state and emit a console message. I suppose we could notice that we were on a nohz-full enabled system and the task isolation flags were set on return to userspace, but we were not on a nohz-full core, and emit a console message and clear the task-isolation state at that point. But that also seems a little questionable; maybe the user for some reason was doing some odd migratory thing with their tasks or threads and was going to end up migrating them to a final destination where the prctl() would apply. Any suggestions for a better approach? Is it worth doing the minimal printk-warning approach in the previous paragraph? My instinct is to say that we just leave it as-is, I think. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com