From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 271D02EEE8C for ; Mon, 6 Jul 2026 17:09:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.12 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783357744; cv=fail; b=ZmHhIy1lB7dhY4ePE5QDFuBJ7WpDhHn+DDLCM+vFHvdScYm9JCwlW5stvEOtNaROyMLgTTGzEktdYxXvASsBdfVmFZAjhW75orCncKiy/FeyfM/foRbZQFRdwNbxVMfm74tLdYgvXz06n4ThlJE8kfLbwj2kNZMyWiIPcP5KzbQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783357744; c=relaxed/simple; bh=/+A5XQlu7ixEuE7qpTjFgR+XCXMyanRSY9zaPVjHMAM=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=APp7lrKdlDtMOnZxVj7RzU9VgskYFQz4HCGYZkSkacJLtJXywAqwUvacRyKtmQlUeXT3I6rWvRlqyvOkOteVuq+DNOtSJcmmh6oge6LGwm6FAVXUGp9wzu4LGqJpN6rsyAtZWnnjYRiTVGJVfGi9kBh+m2Plg2UMH0+4xPStTy0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=YJMLpqkn; arc=fail smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="YJMLpqkn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1783357743; x=1814893743; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=/+A5XQlu7ixEuE7qpTjFgR+XCXMyanRSY9zaPVjHMAM=; b=YJMLpqknB+JHxzNFGFa9IxOSfk5wFGFB1UwFe1xKhYr5Qn4gVpKx4CRO Ud98f38MLr7oXWGai6kFgkzXDnUZEs1nMovGrRMPu3/1w9AIiFpQ7k5Q4 VIMXOQxX7NeRGPHQH45gm4kM8Nsu8kDTGm4BNC+c5XZVtOt3xpuIPqtSD ZQQxi6OjWc2tknUBDg+xbgokX8W4Ya9nI+wHYnqKaDvBRfnFqXPXcLBT+ Eof5HG6hnsN8ODu26DVyeYP7RTQF3BXvdCDml1olHirEtShUOgm4gjj17 VVlxaMGWIGlvv+w8D2W6lRETrhDSC1FtKnHd9t5P3mLuRfj1lgy0JZ8ML Q==; X-CSE-ConnectionGUID: My8mK/pMRg+RpWOlR3XwOg== X-CSE-MsgGUID: eLLexNjbS3KBGrZO1K4FCg== X-IronPort-AV: E=McAfee;i="6800,10657,11838"; a="87819771" X-IronPort-AV: E=Sophos;i="6.25,151,1779174000"; d="scan'208";a="87819771" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2026 10:09:02 -0700 X-CSE-ConnectionGUID: JSj6zTjnTSS4RCzFW7EkxA== X-CSE-MsgGUID: V0VhPEm/TbublXEXZ0cuGQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,151,1779174000"; d="scan'208";a="283864024" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2026 10:09:02 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Mon, 6 Jul 2026 10:09:01 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43 via Frontend Transport; Mon, 6 Jul 2026 10:09:01 -0700 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.9) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Mon, 6 Jul 2026 10:09:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XRKbvokjySKqLHFTA23vFV4fIaBgGD6GjtWifS5WcjpNcxKn6meKLiPW8O87b7shzeCAg7Q7WxrtRNNrKIPeoGCMpANk/BIrq0hq3TnE8GBT9z/JEBQwilqeQsLj0ipE5g2wda7dOHy2VmNt5p3wnMNKPnsfjuwqpznGCuqw8sv6E+QWcMKm25DUUtJaqCoVyaHod9MMR3m9XpZDUhD5LdDyVIluyVi3Uk1R0Igy1/XOHmPJEoxPmjfdEUsJ18UvIgAG/XhDRxSKMib3jLyfVhX0PlboNY6oI2zbjJh4OjZWzxAO2UhUTDG7ySkntu1kJ9pUT8Zum7mGdYoz6o82PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rv6+Rsxjil54SJSmMXrSQXsGsdoiJXPjGjXUIO+CTtw=; b=XnUY4FOb1ZHRD0Ki/uHrvoGl1W8pP4R9ZscwRP8uMCGghuHgFbZ7/efLJYr5I2NuN10esutTnnSoewTPB7aBiFCtY9E8OpmrhNv1JSsu4CCyfIwFZ/n9XiMnFNmE80sBkzzkQJB1PvRDPb3BPkloid1MOLou4u1rfjr+rhFYDFeeWFnjfJd23PpNIg9JHSw3a6tSOWtCGSYwB/s0tGQe9yxPSoA+ZmN1eyZTmO2DY4jLdYWMHfm2kFwaEPQ9AmG9xFGOtDMeaj5Jwf0iIWWyAYbqiRT9qCkFx4oxKIQKKzZzXIlZwSKp/LduMJaMiudsugHRrAi79Y/F6mNmBZ67Ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7925.namprd11.prod.outlook.com (2603:10b6:8:f8::18) by DM4PR11MB6336.namprd11.prod.outlook.com (2603:10b6:8:b9::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.10; Mon, 6 Jul 2026 17:08:54 +0000 Received: from DS0PR11MB7925.namprd11.prod.outlook.com ([fe80::60af:89a0:65dc:9c84]) by DS0PR11MB7925.namprd11.prod.outlook.com ([fe80::60af:89a0:65dc:9c84%3]) with mapi id 15.21.0181.009; Mon, 6 Jul 2026 17:08:54 +0000 Message-ID: <358834b6-86da-4f7f-b2b8-cda31663682d@intel.com> Date: Mon, 6 Jul 2026 10:08:51 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/10] x86/fpu: Allow restoring signal frames with larger xstate_size To: Andrei Vagin CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , , , Dave Hansen , , "H. Peter Anvin" References: <20260615193716.1843340-1-avagin@google.com> <20260615193716.1843340-10-avagin@google.com> Content-Language: en-US From: "Chang S. Bae" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR03CA0178.namprd03.prod.outlook.com (2603:10b6:a03:338::33) To DS0PR11MB7925.namprd11.prod.outlook.com (2603:10b6:8:f8::18) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7925:EE_|DM4PR11MB6336:EE_ X-MS-Office365-Filtering-Correlation-Id: fd032a63-776b-46f1-d93d-08dedb8141ef X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|23010399003|1800799024|376014|22082099003|3023799007|4143699003|6133799003|11063799006|56012099006|18002099003; X-Microsoft-Antispam-Message-Info: e69pbgtIRJkqD2ov69NSKFl0/ASAUfiZ99yFp1y8gHNWgpYXixr6sKhQE5sIFhPl2TnyFxDxadtgMf8EQA3vojbMazByeefNHlHC+sgcdmJjCmRa5+qvEt3oyQ/RX5PXorn2dmDUU1YWSKdPdhY4NxNfXgZPGpQGa8bX04/peqFNoz4zxPXUs0kCCOt2eXV3NXemkMLns5QIH0jB/xHDaFG9SThNH7rehhwen8NcfkJGj8Igyh8kLjePAJnxuxNv5aFzyyP8JMG3sNUT329ZlolU+g5xE4NkbHyMmLm5QMUvrUw/GIy/kdpXpYAQ62K9Un6cFTmCVJBs6cWeb7jWQ3x0bNkpyI+gfn4ynsXAI4oa6CPL1r/dTWXEViEjE+Em+OSdEhj/U+/QQQ/JIdNfU/48Ed+ASQUt8IP9ypGf8xOVRml2eWEQJqSPXeToZJ9xvFT8e2UB20k2ZtvkGmFO/LbDU9olqnCcbijlswcE+c0C8X3C3cP/IWr7e9y43JXRHvPA6l+JFTD45hUNsVNAp69u7Jmtc17PA5iyi/NNRE6r7ohTTDK0rzvsxVCUELYsQrUUryXB8+1ItRN3dPudCN++TMx6xsX2dV95qUe1mujtmrNmrJgKu8hJ4AO3FRSnTXtTQ9Q+gx5t39Oep3kUNLR7MRi01VPbKhYxzz6ff9I= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7925.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(23010399003)(1800799024)(376014)(22082099003)(3023799007)(4143699003)(6133799003)(11063799006)(56012099006)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RkYvL3N6VFpiV3IzUmtrL0xMQlpQalBuWmlzcE1GcWp3Tm1ydG9POE9KK2tw?= =?utf-8?B?Y2hjcy96MXZIMTNqNHM3enVQaDJaMDA1Ym1LVGZCbmdGVGZic1FTTWlDVXl1?= =?utf-8?B?TEVzWnFkYUlFOWt4NHlrZlNRK3hTb0IrRzFoVU4ySklUdGp4TVBGTEVVQWVE?= =?utf-8?B?YXhGNHMybGp5SDZJcmUrejM4ekZrUmcreXhHa3RDRGhaMHc0Wnl1VG9iOXN6?= =?utf-8?B?T3VYczFzcnFWLzNmUHhYTldiZTQrK1VSSEhocUhUUTB0ZDU0UExJMXhzb1Vt?= =?utf-8?B?ZHhzNjRhL1gzK2RKemFmTmVnelBZODlOZStxY1pMTlZZc29LS0o0NHZTSlFF?= =?utf-8?B?YjUwTi9ySFkzU1p6WDBKUVg3dm1HWjlVNGZzZnNtUnNDRXRPVXpYUjNXR0l5?= =?utf-8?B?YUZrbXNDWVVLb2JJbXlPVFY3bnNiYmV3ZjJMU2x4akdjQjAydm9kcU9MR0hM?= =?utf-8?B?ZG9UUTNEWFNpelVEQzQyRkg5U0lJSUNNejZmK0haVnlxdkVvUjZXQ3hDL1dU?= =?utf-8?B?RVFheU5iMU1iUUxvcHpoVEdUalFpek5sYVB5NXlPK2ZiUk9vWTNkNVlaeksy?= =?utf-8?B?Vk90WHNDM1Bzb1pja1M1Y2t5WTF0TzBVZUV2LzNUUWRWSkVoQ1NTWFNSRitF?= =?utf-8?B?MjNzRjBPK0Nway9pTjhvNjUweGhHOHYzOTVNZmZxcC91NlZ5bGQrdGVJa0FE?= =?utf-8?B?L1Z3MWZ4V3JORFpiR0RVZ3RVZ0hPdit0bFphOXJ1c0VKN0Q5aERUcEk5ZDhD?= =?utf-8?B?M0JhRXFoR3p4UnF0YWliWkFGYlg2V0JTdVpad1RXeUU1MzRVTHlVRzd5RFUv?= =?utf-8?B?VldyemYveUVnd3IzZEMrZzlhMmJyUU5lb2ZmRExhZUtPeCswZmllZmR6SFhC?= =?utf-8?B?aXVlbDF5czA2S3hvTlJ5NzVRWmk5Ry9xbWZiY3B4ZWNGNERTanVVTHpVb0hw?= =?utf-8?B?K0tOMWtLeE5ydUhXZXZlQVVRSW16VFJ5L25FN1p0a2NqQ3Y1MDk0TXEvdzZk?= =?utf-8?B?akVnWXlFZVkvcUtkM29GL1VDaG5mZ0xyZFhQbUZDYkVubnZvbmltWEpqaXVR?= =?utf-8?B?QitOanVtcEZIOHpYRU9LTHgxY3dkdVRFb1Z0aGtQZzZBd2VteitWbkgxdkdD?= =?utf-8?B?RlRjdkh6djVKY1FPa3FhZVFGZ3BzU3dJM1pUL1dyNjdEczBqTE1ha2RsWnBJ?= =?utf-8?B?N1U3RHRGWk9namtyMXVTOW96YlhRTHpHalBTK3hYOEFYWVEzd2ljbW9hd3VB?= =?utf-8?B?bXZRU0JLU0hUdXpvVnJxd3E5Tm5CUDRJZHNjVHZkaXJIcklZeHdiOGJ3MnZq?= =?utf-8?B?WDNrRFRyakJYN0RUcVlaZEo2cVdXZkNNdlNXWkF5UjY1alM5akpkdkFYZGRZ?= =?utf-8?B?aGVURE1FeFRDUmREMDBmU2dIRk5MVWU2c1YrRWZaY01WMURTSWROdU1qLzY3?= =?utf-8?B?bEM5bStzVVFSSndhekhvem5xQVRId3FoRVIxUjFXS3VXZENUc2hFN3JkbjlL?= =?utf-8?B?QlFlNUtIeEhZN0JqT0kxQUhxSlp4OWlkSkZ5ZTNiK0RYVXRaa1ZHKzRBYzFG?= =?utf-8?B?TzJwMUEraURLcHBTTDFiV0hwSkVZR012WXA5RTRWNUFUaEdYeGNWaG9XYUNi?= =?utf-8?B?dTUyd0FnWG9wT3M5NUxaSGthZEVMczgvS244b1hSWEhBWktrWE9ONm10dC96?= =?utf-8?B?WE15UzZMcWo0TkRIem01L05IQXUrYkFCZk1nYm9qTVhEa2cvSkdPQ3N6TTIz?= =?utf-8?B?b0dwWjRJbWI3SkQrOTBlb3RmU1JDRWdzTVM5ZnZ5eWdCMHNVQzkvdE0zb25R?= =?utf-8?B?RU96ZUpkRTRVVEF3SmNnT1N4em0xc2FDY1owYXhnKzN0NFIwL0o1STRPcG9p?= =?utf-8?B?WWQrRFdydmJLZjVEeEVDd21SQVVxL2dkRWtpWHd2bldGM1RoSjRDVHlxNGpM?= =?utf-8?B?UzFmWmQzQnFFWHdYUjdaTEpzYnZXYVpqRVkyaTFIaTNVdHZpYk5tbWJkU0Uw?= =?utf-8?B?TWpacVhJTEpRaVZaUU0wMzJYRnJjdHlGYlNhc2hzbis5RlkwMFFPODdvYjJq?= =?utf-8?B?OVpweWhEbHRxTnNKdUgvUndqVUZlc2NlY1ppOUhNM05vSFJLRjQwM1JNeElW?= =?utf-8?B?cHNYeHVWSGxUQm85T3NxNVdaN2lyUHV3b01IRjM2cDZ3WXBHRkhJVUZ2dVB5?= =?utf-8?B?ak1BWWphNE42cER2WFc0ekhKRk1CaTFJcnk2N2VjWlVYVDU2b1J5TWpsVUQx?= =?utf-8?B?TW40Tm1DZjZqVXkwRGZvcCsyMHNYR0wrTm4xWW94WkRvVEN3aVo3U3Q4K0lC?= =?utf-8?B?bURyYnIzZC9TaVp3UFI0VnppT1pScUNNY3R6SDY1bE5LY2g0bmRWdz09?= X-Exchange-RoutingPolicyChecked: ACfo37sWacPqK0Xq1uSOI/npLsHcoKQ1lRGWIJNKKWOCOTzjgjZB3J4oZnAozhshhc5AMu3K7dss40r3fLnXHsc4hwcgAmgF67rQu+vPGrYLP/BMdRjuB7Mu60DdUe8qa5Dha849Nmmqh/8CUTRB7TkocU/O03vnGHlWj726YryDlgeHcFBpLMXSTlnxLoqdTD5xEzT6/ujN4HlWauFfxBgCG4J58YLTI/MtFdUhSS8ZfiojcWnKfefYmpD745qUX2l8PdMWOnQMMs7lT8dGhxno0WUSNqqI9rk2aMBUIsOYNNXF6PBQ3AByiN8ponOXeItAdyJT22gBUS671RcRIA== X-MS-Exchange-CrossTenant-Network-Message-Id: fd032a63-776b-46f1-d93d-08dedb8141ef X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7925.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2026 17:08:54.1080 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8EKKF8SFg2O4AxqpO580wQr82/y3Emkj7Cymz67miML4Jn36S/PYljJB4++vpfbRbwpMGjonPwEqpdIbnfk5hLxPucZYjueJhdE0jbnLsyo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6336 X-OriginatorOrg: intel.com On 6/30/2026 5:48 PM, Andrei Vagin wrote: > > In our previous discussion, I explained why the state translation > approach doesn't solve the problem: in-flight signal frames on user > stacks cannot be translated. When a process is checkpointed while > handling a signal, there is an in-flight signal frame residing directly > on the thread's user stack. There is no way for userspace tools to > reliably discover arbitrary in-flight signal frames embedded in stack > memory. > > We want to support cases where processes using only cluster-wide > available features can be migrated from newer to older CPUs. If we > migrate from a newer CPU (larger default `user_size`) to an older CPU > (smaller `user_size`), enforcing `xstate_size <= fpstate->user_size` in > the kernel unconditionally rejects valid signal frames. > > An fpu translation mechanism already exists in CRIU to restore current > per-thread FPU states, making it possible to migrate workloads between > different CPUs even today. But there is always a risk that a process is > migrated at the wrong moment (while running inside a signal handler). > Without this change, failing the size check on that in-flight stack > frame can trigger a state corruption. This patch eliminates that risk. So if I understand correctly, the intended usage model is a cluster of machines exposing a compatible set of xfeatures. Migration may occur in either direction (old -> new or new -> old), and the process image, including any inflight signal frames, is copied verbatim because interpreting or translating arbitrary signal frame is either impossible or at least not reliable. >> With APX, userspace can no longer assume that a higher XSTATE component >> number implies a higher offset within the XSAVE image. Going forward, >> migration software will likely need a more robust approach that >> interprets the layout and transforms the image when moving between >> machines with different layouts. With such translation, maybe further >> relaxing the kernel-side checker isn't that needed. > > I think APX was designed to preserve backward compatibility cleanly. And > I don't think that we rely on the assumption that a higher XSTATE component > number implies a higher offset within the XSAVE image. > `xstate_calculate_size()` already finds the topmost feature by offset. The > only reason the kernel needs to know the required xstate size is to > correctly pre-fault the user memory buffer. > > While APX reuses the MPX space in the xsave state, it introduces a new > feature bit to indicate the presence of its state, which is really what > matters. The actual register state that gets restored depends on > `task_xfeatures` and the header's `xstate_bv`. Any attempt by XRSTOR to > restore a header containing unsupported feature bits in xstate_bv > generates a GP fault. This cleanly traps in restore_fpregs_from_user() > and fails out, triggering a SIGSEGV. IIUC, this works because the migration pool is already constrained to architecturally compatible machines. In particular, APX systems would not be mixed with older MPX systems. Otherwise, while with a distinguishing feature bit though, the layout is still ambiguous without interpreting signal frames. > > I completely understand that some features may be deprecated in the > future, but I still believe that for non-deprecated features, component > offsets should be fixed across all CPUs within a vendor's family. If > this assumption is ever broken, even standard KVM live migration of > guest vCPUs would break. > > Sorry if I missed something. Maybe you can give an example of when > this change would work against us? With dynamic XSTATE, suppose a take has opted into a dynamic state and therefore carries a larger xstate_size, but it is migrated to another machine where the corresponding dynamic permission has not been requested. Since, according to the usage model, reliable interpretation of arbitrary signal frames is not possible, I assume the migration framework does not inspect each individual state to determine whether this is still in its init state or not. If that's the case, is there a possibility that meaningful dynamic state could be lost during migration? More generally, if ever reconsidering the kernel's sanity checking, one concern I still have with this change is validation in the presence of unknown future feature bits. This series does not run into that problem in practice though. Thanks, Chang