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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C0D8E65D2C for ; Fri, 22 Nov 2024 07:31:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 913AA6B00B9; Fri, 22 Nov 2024 02:31:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89D836B00BA; Fri, 22 Nov 2024 02:31:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7168F6B00BB; Fri, 22 Nov 2024 02:31:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4C6A06B00B9 for ; Fri, 22 Nov 2024 02:31:33 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C965881715 for ; Fri, 22 Nov 2024 07:31:32 +0000 (UTC) X-FDA: 82812908094.03.29AAAB5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 421F940007 for ; Fri, 22 Nov 2024 07:30:24 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L8gUn1cu; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732260504; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PXq9Wjiti00hPsb6uBFVS+EGZ67OZCcyDnwcfoAoCsg=; b=ibt1oid+vIml26NZ6xVw4a0PLtOyB25OKsUl7/v61Pt1j/DOXBqN9Uc12prKQO0Iy1nUMH hX6wxfwjkhLF3MViXb5fO4+FD3tLoWdck1qJUEBARR6xKqhIY2eAq8RbFwlaUlDCanjQSw vXfFm3baX1oEspe1BU23GPswkSrnAdQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L8gUn1cu; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf11.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732260504; a=rsa-sha256; cv=none; b=qJ1IkbLDRkN6yZa3R0pG1AfrMEEWmH+ljR4/XiPZ+5hXRO9oxUqJVT4LWylLpkg1FVNwYB hvJcCcW/+/peXhqDG+KQrkX+g7RhSpetImc/i8inV9L1G5nDPOKGD4iKG9o2PkeY9d7ozv MnHv+oRtUz3Paujl1MgR2GZ6Xh5YSqs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732260690; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PXq9Wjiti00hPsb6uBFVS+EGZ67OZCcyDnwcfoAoCsg=; b=L8gUn1cuaPeEPv5GU4jo9q+JJztMmIBWRZIwv3oI80MAIfaN0yjQSKjEHDq/OP1yN5MwLw qnHieZRlIXfgEnl/NqMSRIHRFZNtS9oud+9Vqmn9pIB7qz/YfgS8rIOeg9Ow3gjuMEzXjh mgGD9fETSQWJpTl17qB1DvgoVjg2qCw= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-641-sLMKtwRkP9C3ZZ084QJlQw-1; Fri, 22 Nov 2024 02:31:28 -0500 X-MC-Unique: sLMKtwRkP9C3ZZ084QJlQw-1 X-Mimecast-MFC-AGG-ID: sLMKtwRkP9C3ZZ084QJlQw Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E8D46195608A; Fri, 22 Nov 2024 07:31:25 +0000 (UTC) Received: from localhost (unknown [10.72.113.10]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DA2AF19560A3; Fri, 22 Nov 2024 07:31:23 +0000 (UTC) Date: Fri, 22 Nov 2024 15:31:19 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Vivek Goyal , Dave Young , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , Eric Farman , Andrew Morton Subject: Re: [PATCH v1 07/11] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel Message-ID: References: <20241025151134.1275575-1-david@redhat.com> <20241025151134.1275575-8-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241025151134.1275575-8-david@redhat.com> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 421F940007 X-Stat-Signature: i9swrnbksg7bctpz66xzir7tx3ophr9h X-Rspam-User: X-HE-Tag: 1732260624-155467 X-HE-Meta: U2FsdGVkX1/x95yN4PLi4FmZHkY6VoQ6n+03UsUpsXh83lq1jcdOK6Ony9IKq4AOnSuuQ3FcoZR4JEORDDNV+sleZOX1Dnzdrur35VWeKgpzCq2xLbtCcfqHWlQ9e7EKrVhGl/RXVORMb2swpvMrfafqKjviIGlYmDfMwy4+XVPSwPQhxU0XN1pkbZQnYI1l0kBl+icpwrDaXr8iKiim1hJG+mWTB8Vx2m4nWUDuf6FrCphuOpPO+0i4qcBQBcHoEz6dLwrdon9bw9U8hu1YJ16NH1iow6Hf1daWQ9upOTu8RaTw4jldaZQFvNbZnINP0mYY4OOrLSu0aNsUL2mjYGdMI8QBHzCnPhmsY2tstMtEpXv4RfppwJSgGWSMSlnKOcarfEz4bsV+4d13gaMNWvkGAEArPUdY9fwfcDYP0tNPMGnB1uoydW08pMTdTViMYzn//RMTkxyC6zdSBgqIjn0OKi5wtOu+SCISur+9rrAVsOdCQNMMK1k0gJCj4gj0rIEwqI8rU/2SCS4l5HUwVImcZvJO7XnzZ7sxTCH2Jwwalv0/Yhj3Q2XC4MNLX/3BLKlTqInnulduh93m0BfbWrWshK2TnRq9+oAs27ClG8Z77OqDIjBqaxxJr/y2LRCfpjE/+rdDqVFNwbk29rfeFkil0B2fdjXlmeLOCNQK9dwhvf+4Zc7CPuu6u/1Sv5lkXFTSrpnMj9zRLEU+dnO6BfNqC4HS2BKBrUIg6PKJIGUa2CAFkAv7cZCG7iWJtyjBGOhRk/c3v0rba75K035iwgdBCZ+eJjVw8bQnP3qFWX+/SnqzE3i1BovLyGlMTi1hoW5vm29ciOEveoggVOeqgG9czwqI1IlmY5j8d8YtjjHQ+Lkio+UdPbQZixN6SromKwPSeVepDq3wujJXYTWQi5Gr9tvC1hNgJe2oJs3w6FeQb0t8aPWzY9REt97392pZBMz6jIsjylh8L0ZV7Gh dg7TrQaM E0VBjlYs0Ift1+p2tUYJIpSXwL+M9ePHk1iPfRkMgWq05pZMXxwx/NG0OcRTaWvfMJ4+govmNfHswgTRnynCWkw2QbUueZEVffcHZTK786vQ1egP+Qe6rErepmdWgtgpnDGxU008uA+AHiAIKEs/TEp4CqNcQ0PqA03k2qrlYal/328PqTl2boQtMFcuXZ75DQb90tZuOIgk0/ujM8sopwDgFlYUMkVggiXL6JZKp6Ud0eLA68yhur+OyNn1LXwzTZfOoZgrZN2BfqAQpuReHnikVJp7JaTFb6HEe4sjsFROaCUPfbzS90fMbBMhSygg5bwF4tEhNOdORjqG5n1jpzn+BLAbT0ylLo4RcikNOfm6THUBphhrGDj5YfxCbj2G6hr+VSn56NJPtBq/DYPvsojGdDw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 10/25/24 at 05:11pm, David Hildenbrand wrote: ......snip... > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index 3e90416ee54e..c332a9a4920b 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -69,6 +69,8 @@ static LIST_HEAD(vmcore_cb_list); > /* Whether the vmcore has been opened once. */ > static bool vmcore_opened; > > +static void vmcore_process_device_ram(struct vmcore_cb *cb); > + > void register_vmcore_cb(struct vmcore_cb *cb) > { > INIT_LIST_HEAD(&cb->next); > @@ -80,6 +82,8 @@ void register_vmcore_cb(struct vmcore_cb *cb) > */ > if (vmcore_opened) > pr_warn_once("Unexpected vmcore callback registration\n"); > + else if (cb->get_device_ram) > + vmcore_process_device_ram(cb); Global variable 'vmcore_opened' is used to indicate if /proc/vmcore is opened. With &vmcore_mutex, we don't need to worry about concurrent opening and modification. However, if people just open /proc/vmcore and close it after checking, then s390 will miss the vmcore dumping, is it acceptable? > mutex_unlock(&vmcore_mutex); > } > EXPORT_SYMBOL_GPL(register_vmcore_cb); > @@ -1511,6 +1515,158 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) ...... > + > +static void vmcore_process_device_ram(struct vmcore_cb *cb) > +{ > + unsigned char *e_ident = (unsigned char *)elfcorebuf; > + struct vmcore_mem_node *first, *m; > + LIST_HEAD(list); > + int count; > + > + if (cb->get_device_ram(cb, &list)) { > + pr_err("Kdump: obtaining device ram ranges failed\n"); > + return; > + } > + count = list_count_nodes(&list); > + if (!count) > + return; > + > + /* We only support Elf64 dumps for now. */ > + if (WARN_ON_ONCE(e_ident[EI_CLASS] != ELFCLASS64)) { > + pr_err("Kdump: device ram ranges only support Elf64\n"); > + goto out_free; > + } Only supporting Elf64 dumps seems to be a basic checking, do we need to put it at the beginning of function? Otherwise, we spend efforts to call cb->get_device_ram(), then fail. > + > + /* > + * For some reason these ranges are already know? Might happen > + * with unusual register->unregister->register sequences; we'll simply > + * sanity check using the first range. > + */ > + first = list_first_entry(&list, struct vmcore_mem_node, list); > + list_for_each_entry(m, &vmcore_list, list) { > + unsigned long long m_end = m->paddr + m->size; > + unsigned long long first_end = first->paddr + first->size; > + > + if (first->paddr < m_end && m->paddr < first_end) > + goto out_free; > + } > + > + /* If adding the mem nodes succeeds, they must not be freed. */ > + if (!vmcore_add_device_ram_elf64(&list, count)) > + return; > +out_free: > + vmcore_free_mem_nodes(&list); > +} > +#else /* !CONFIG_PROC_VMCORE_DEVICE_RAM */ > +static void vmcore_process_device_ram(struct vmcore_cb *cb) > +{ > +} > +#endif /* CONFIG_PROC_VMCORE_DEVICE_RAM */ > + > /* Free all dumps in vmcore device dump list */ > static void vmcore_free_device_dumps(void) > { > diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h > index 722dbcff7371..8e581a053d7f 100644 > --- a/include/linux/crash_dump.h > +++ b/include/linux/crash_dump.h