From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CF7C3DAABD for ; Thu, 6 Aug 2026 06:22:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785997331; cv=none; b=HKStj9PmK+OYPo32ndyA8OMEURNtV0ERn63mwGs5N7AsGSir8kh2Z8on6HkOyqrrwIkPIe32JAvOZj3Rm2HZCfynD8xIQyLy7C3mWLx7GEj/eq/l2RtRKZZ+K56w7MzZuv0piPpGnhublJSmuwdHT9mvks8uYFrIcS3BrLnlQdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785997331; c=relaxed/simple; bh=xdMK4ivvR/JqsYu6ADRtq7pL2s8RgJFSH3/XUshNPWU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QEGpDWpHwnvt0hmRJ5ndX/nqXzncvOnaA+1OCDxXGz/W9cU/J0gcdUDLh4hOHRtMh/lq890UXLhQGS9mxjuyflNf1foZugRvNXDKzSa4VTqng6mnsEyjyzLwngyNaiy1HxreHPPixN+loR8qTDlFcK0eAZzWcxOR+WTF8Fv/NxQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TY3kytmo; arc=none smtp.client-ip=209.85.210.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TY3kytmo" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-8485ef63b68so2608668b3a.1 for ; Wed, 05 Aug 2026 23:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785997329; x=1786602129; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=3SOAFOHhNdPiE/zVJtR+92drLkni05r7F3CCyaWM+hc=; b=TY3kytmobHyK2J0EPC88a5DsQFEMM+zeVOy3ObqUgPfXAbKIsANCwpHfAE9c0LxEZJ D4rmSwyH+wkqOiSfasN/uPXl2lRZkZ/GS9gvOQGsZe30l+3eP0wIZWI8EXMLTRRCGKmG tFn3V0wL8Jaof5En7rCyBVfcG0hcno0Ll9Zag8xvMLsvjj1SkhefUnq564c36Ugp0TB9 LUVeP2TkNvu0J36BVA94H0KtHV9GnVYuIjB+KTVn0KEeSvJp1VHoB7F3twMrv2Mpv5uo 1yDevvmRrbg9KVNqGXAZQvipJV3u8acyjo1IzD3KsVAKAJ8hP4IPsEtMhvqMO0wWalt5 8xKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785997329; x=1786602129; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=3SOAFOHhNdPiE/zVJtR+92drLkni05r7F3CCyaWM+hc=; b=Qho/CbNPyteKanpMud+hkK3DqbwQK/UFBUahDRIWF97P7zkwUuBD4m+js2rV5Pmw1L 3FGBWO+n3Bd/ndPavdcu/NxS1wSBn3IzBOBgX/jQzSJkvebWMWvC/HZ4I0DeVxPbRBbu 0ZbpBcj/YkX6PVMFVljVGsWjQin4n9/S7ZlWtNjmWVA3pBceK9O3chUQ1yBSLKq2AULN YRZkS1LM4efP0JApwsVegnIHeasZln1qRd8Ox3emjPtjRXrfP3ZcdZ5WTlz9hLlGqJDd 5pstofzszpsNhtcqa7o1XhYt7BOBRDUCKBFKKw8+TwhCgn7Xmppl8JtBawet6QQLlVsd AiuQ== X-Forwarded-Encrypted: i=1; AHgh+RrJCln2By1aHpRFLXeEuCoigKpD7qoaj9s9RGWFF0JWM0q+uOi1KzbM9Ffmg4SbnqCr/pQR5xd+Rh6XaFc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1IwkWIhlDXzNnD+/awJjJ7wPUPuvDM7HA1ToN9vIMwC0TVxxo /gz/sAia//dZ+Q21pr5EouE8GVSdQ3tnFfSgC+teIL/mQw8biaAJaTQ0 X-Gm-Gg: AR+sD10RSVsUUUrT7gBNp9FOjj0FyzsMkGHKnjgmECLES7q1KUoVARPSdg+AtgI1X0b Lj0ePpuhgXtKT8xv+yaRvMWJqSTHo/Er7W9/nX0gFZFo/pdPGsG6HLHLOXlCdp15fU7mfOdUUeK RVrtkhStwxJcG/C5InjpjIa4DFZPQ7ly+EBQ2ViKW31UCEWp3XXcnYa8N4OV0bM3fORrydAWU77 nFMFuco5UsvyyIpZmXgWuAllG5W/v0Qrnl3GcyZAnfRISUgSxBYVRPN5ETn9JM8rT0bbxUrch/A QEbvVartbZJ+ki+SNlxJFuobtoLA5M2rENnI2OHntD9JrjlIM7L17J2P7GD56A0o2+86+StVbJQ P6AZxtIQXovQB9gvvwz/oZKoR3iwmLcBBpc81BYIVwan2nN9lXHgSVOuP9DWJe1kVHboONGysC0 P5N29G6V4ui5JZScX8+z5CcigKOPCh7LZUuKV2lSxmBG4= X-Received: by 2002:a05:6a00:8d81:b0:847:7f3c:b5f5 with SMTP id d2e1a72fcca58-84f2dfc8f83mr16142823b3a.11.1785997329428; Wed, 05 Aug 2026 23:22:09 -0700 (PDT) Received: from localhost ([2a09:bac5:55f3:25af::3c1:3f]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84f459ba50fsm659110b3a.42.2026.08.05.23.22.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 23:22:08 -0700 (PDT) From: Coiby Xu X-Google-Original-From: Coiby Xu Date: Thu, 6 Aug 2026 14:20:39 +0800 To: Sourabh Jain Cc: kexec@lists.infradead.org, Andrew Morton , Baoquan He , Dave Young , Pratyush Yadav , Mike Rapoport , Pasha Tatashin , Coiby Xu , open list Subject: Re: [PATCH v3 04/10] crash_dump: Read the number of dm-crypt keys from reserved memory Message-ID: References: <20260729033654.311541-1-coiby.xu@gmail.com> <20260729033654.311541-5-coiby.xu@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: On Wed, Aug 05, 2026 at 04:35:50PM +0530, Sourabh Jain wrote: >Hi Coiby, Hi Sourabh, > >On 29/07/26 09:06, Coiby Xu wrote: >>In case user adds/deletes the keys by mistake, it's safer to read the >>number of keys from reserved memory. > >I am not sure how we differentiate between a key being deleted >accidentally and a user >intentionally deleting it. However, I have a question about how the >kernel handles key >addition and removal. > >How does the kernel handle key add/remove operations to keep the kexec >segment >corresponding to the key header up to date? > >The reason I am asking is to understand what happens when a user >deletes a key. Does the >kexec segment corresponding to that key header still retain >information about the deleted key? > >If it does, could you explain why? If it does not, could you explain >how the kexec segment gets updated? Thanks for the questions! When a user delete a key by removing a configfs item, the kexec segment still retain information about the deleted key. The kexec segment will only be updated when the user tries to reload the kdump kernel. Because I think introducing a sync mechanism to automatically update the kexec segment when there is a change to configfs is unnecessary. > >Also, for my understanding, could you please point me to what exactly >is stored in the key header's kexec >segment? During restore, kernel access the old kernel memory using the >information stored in that kexec >segment, so I would like to better understand what data it contains. What is stored can be known from struct keys_header and dm_crypt_key, struct dm_crypt_key { unsigned int key_size; char key_desc[KEY_DESC_MAX_LEN]; u8 data[KEY_SIZE_MAX]; }; struct keys_header { unsigned int total_keys; struct dm_crypt_key keys[] __counted_by(total_keys); } *keys_header; [...] -- Best regards, Coiby