From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B87BC4167B for ; Wed, 6 Dec 2023 15:20:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379303AbjLFPTx (ORCPT ); Wed, 6 Dec 2023 10:19:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379088AbjLFPTw (ORCPT ); Wed, 6 Dec 2023 10:19:52 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 077F8C6 for ; Wed, 6 Dec 2023 07:19:58 -0800 (PST) Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 14FB521E97; Wed, 6 Dec 2023 15:19:56 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id ED5A2136CD; Wed, 6 Dec 2023 15:19:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id wubtNhuRcGUjSgAAD6G6ig (envelope-from ); Wed, 06 Dec 2023 15:19:55 +0000 Date: Wed, 6 Dec 2023 16:19:51 +0100 From: Michal Hocko To: Philipp Rudo Cc: Baoquan He , Donald Dutile , Jiri Bohac , Pingfan Liu , Tao Liu , Vivek Goyal , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, David Hildenbrand Subject: Re: [PATCH 0/4] kdump: crashkernel reservation from CMA Message-ID: References: <20231201123353.2b3db7fa@rotkaeppchen> <20231201165113.43211a48@rotkaeppchen> <20231206120805.4fdcb8ab@rotkaeppchen> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 14FB521E97 X-Spamd-Result: default: False [15.00 / 50.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_FAIL(1.00)[-all]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_QUARANTINE(1.50)[suse.com : No valid SPF, No valid DKIM,quarantine]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[]; RCPT_COUNT_SEVEN(0.00)[11]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-0.00)[39.47%] X-Spamd-Bar: +++++++++++++++ Authentication-Results: smtp-out1.suse.de; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=suse.com (policy=quarantine); spf=fail (smtp-out1.suse.de: domain of mhocko@suse.com does not designate 2a07:de40:b281:104:10:150:64:97 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspamd1 X-Spam: Yes Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 06-12-23 14:49:51, Michal Hocko wrote: > On Wed 06-12-23 12:08:05, Philipp Rudo wrote: [...] > > If I understand Documentation/core-api/pin_user_pages.rst correctly you > > missed case 1 Direct IO. In that case "short term" DMA is allowed for > > pages without FOLL_LONGTERM. Meaning that there is a way you can > > corrupt the CMA and with that the crash kernel after the production > > kernel has panicked. > > Could you expand on this? How exactly direct IO request survives across > into the kdump kernel? I do understand the RMDA case because the IO is > async and out of control of the receiving end. OK, I guess I get what you mean. You are worried that there is DIO request program DMA controller to read into CMA memory boot into crash kernel backed by CMA DMA transfer is done. DIO doesn't migrate the pinned memory because it is considered a very quick operation which doesn't block the movability for too long. That is why I have considered that a non-problem. RDMA on the other might pin memory for transfer for much longer but that case is handled by migrating the memory away. Now I agree that there is a chance of the corruption from DIO. The question I am not entirely clear about right now is how big of a real problem that is. DMA transfers should be a very swift operation. Would it help to wait for a grace period before jumping into the kdump kernel? > Also if direct IO is a problem how come this is not a problem for kexec > in general. The new kernel usually shares all the memory with the 1st > kernel. This is also more clear now. Pure kexec is shutting down all the devices which should terminate the in-flight DMA transfers. -- Michal Hocko SUSE Labs