From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4356441C38; Fri, 10 Feb 2023 16:59:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF7E1410EA; Fri, 10 Feb 2023 16:59:28 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id DC2D6410D3 for ; Fri, 10 Feb 2023 16:59:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676044766; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cGsKzQgK90yHLp2jZLNyJ6Hzt1Wx7PbYgpuKukn+KJU=; b=jUsTegV0OikQP3djMFldl4S3/AI03guKjW9zN8BFFPHBCyqB5r4qFwHz3eS9bO/Cxql9N0 esNZoKrL6SfytyOE77nKoeUxKDbhTAcs7QIcY6+14JTXp2J7w53Co+3xIhX4rlloaI0wD8 6ccMCp+ZgoSCh1dJ0I5r85A6MCFHKQk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-489-NxMWiclSO4OyCWF0xKp--g-1; Fri, 10 Feb 2023 10:59:22 -0500 X-MC-Unique: NxMWiclSO4OyCWF0xKp--g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8017E882822; Fri, 10 Feb 2023 15:59:22 +0000 (UTC) Received: from [10.39.208.22] (unknown [10.39.208.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7851040CF8F0; Fri, 10 Feb 2023 15:59:21 +0000 (UTC) Message-ID: <794fa560-6160-a582-ae3f-5d08e4395556@redhat.com> Date: Fri, 10 Feb 2023 16:59:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v3] vhost: exclude VM hugepages from coredumps To: David Marchand , Mike Pattrick Cc: Chenbo Xia , dev@dpdk.org References: <20221206150509.772408-1-mkp@redhat.com> <20221207165408.895018-1-mkp@redhat.com> From: Maxime Coquelin In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Thanks David for the report. On 2/10/23 16:53, David Marchand wrote: > Hello Mike, > > On Wed, Dec 7, 2022 at 5:54 PM Mike Pattrick wrote: >> >> Currently if an application wants to include shared hugepages in >> coredumps in conjunction with the vhost library, the coredump will be >> larger than expected and include unneeded virtual machine memory. >> >> This patch will mark all vhost huge pages as DONTDUMP, except for some >> select pages used by DPDK. >> >> Signed-off-by: Mike Pattrick > > I noticed the following warnings today on my f37 kernel, while running > a vhost-user/virtio-user testpmd setup on next-virtio branch. > Linux dmarchan 6.1.9-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb 2 > 00:21:48 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux > My system has 2M hugepages, only. FYI, I don't see it on my system which is using 2MB hugepages too: Linux max-t490s 6.1.9-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Feb 2 03:27:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Almost the same Kernel BTW. > > $ rm vhost-net; strace -e trace=madvise -f > ./build-clang/app/dpdk-testpmd --in-memory --no-pci > --vdev=net_vhost0,iface=./vhost-net,client=1 -- -i > > $ ./build-clang/app/dpdk-testpmd --in-memory --single-file-segment > --no-pci --vdev > 'net_virtio_user0,mac=00:01:02:03:04:05,path=./vhost-net,server=1' -- > -i > > Then, on the "vhost side" testpmd: > ... > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_NUM > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_BASE > VHOST_CONFIG: (./vhost-net) vring base idx:0 last_used_idx:0 last_avail_idx:0. > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_ADDR > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_KICK > VHOST_CONFIG: (./vhost-net) vring kick idx:0 file:391 > [pid 59565] madvise(0x7fa6d8da4000, 2052, MADV_DODUMP) = -1 EINVAL > (Invalid argument) > VHOST_CONFIG: could not set coredump preference (Invalid argument). > [pid 59565] madvise(0x7fa6d8da5000, 2052, MADV_DODUMP) = -1 EINVAL > (Invalid argument) > VHOST_CONFIG: could not set coredump preference (Invalid argument). > [pid 59565] madvise(0x7fa6d8da6000, 2052, MADV_DODUMP) = -1 EINVAL > (Invalid argument) > VHOST_CONFIG: could not set coredump preference (Invalid argument). > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_NUM > VHOST_CONFIG: (./vhost-net) read message VHOST_USER_SET_VRING_BASE > > Looking at the whole trace, only madvise calls with MADV_DODUMP (with > all of them for a 2052 size) fail. > > I did not investigate further. > Could you have a look please? > > Maxime