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 B03D145B4C; Tue, 22 Oct 2024 16:47:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B1F24029B; Tue, 22 Oct 2024 16:47:17 +0200 (CEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by mails.dpdk.org (Postfix) with ESMTP id 32CCE4029A for ; Tue, 22 Oct 2024 16:47:16 +0200 (CEST) Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2fb3110b964so50966211fa.1 for ; Tue, 22 Oct 2024 07:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729608435; x=1730213235; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ZM5iXduw3TwLhlSETJMPJNZGlcWlO+bJc8hgp+MhVo4=; b=e23u40VXJofiYkeu3bTkyshiVAhb8MBnN8N1ZUp33IAnWHxCMPfLI0UIKsw4ms4lh5 ldI78Gm5MkXA82NxzOcwdaBN9WINjpfOQuznkUw0z6KXj8T5JJwkSeBBUlLKKFoiINA9 Sdvv4Je31JuRjiVbEtBmJbWdjsLT4VtPch7C8RYB656K4q/j0egZHiUTs2hFcZ8zMeod bfIRY4zc1bH/z4H2jJRcGyQjCUTqLdZuwbLZVvbRPrxAylh6zqbNo0SC/UeM5WqoCQ+8 FgS7xb75RjGlvdpwX7bcr16dD4wDG0E4b9162Filx/grHtXOeqbWJP85pbYE4oLXFZpS T2Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729608435; x=1730213235; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZM5iXduw3TwLhlSETJMPJNZGlcWlO+bJc8hgp+MhVo4=; b=eNqSRSzAAX/lKogmTPI6M2g+X1kk89c3bpB3CJzfl3dA5Z89RZPLqfpWEBjfKK28sd 4s344SMGLjKe6U6comhHqaQRn6LovRSlT02+yFSEtXz7uLVKTHYGm1KZN+P1p7ydJLdM vKmjMEZ4sOOJ14HUlBYOxIgAg+hj1ywU+1oanvennRLpiRsdaeLTU6k3ErbjD4I+ySBh jvpB+SwowgdL+v+lzCkpBxES8znM0yj7DaZitCHJIhTMGmcUFLmKX5UTs/wLabB2EjIL d4mRflBmPco4/nojPy6smC0ArdsjJg0mMSqiNAwXs6bImR6xALjhGvtYMxvgR+u+5mzE 1Xmg== X-Gm-Message-State: AOJu0Yz+LQxdB3S4my9x/DzIhm83tUrAU9uMl2kLb38OJgbQ9N7J+bQ5 UbFNIw0uQ4GPRLKEauuo+g5Ecuaic8Expa++Pp407pEkYt6a2NOzad6lOhfB X-Google-Smtp-Source: AGHT+IFUh2WaQbc39xLmGGJqPk4LYW6Wkr8RXCLCEv8SpYx074xQNYeW3Wbm2cLgL8wBb7B5xVZ+6Q== X-Received: by 2002:a05:6512:3d90:b0:539:e513:1f66 with SMTP id 2adb3069b0e04-53a154f9114mr8030212e87.37.1729608435105; Tue, 22 Oct 2024 07:47:15 -0700 (PDT) Received: from sovereign (broadband-109-173-43-194.ip.moscow.rt.ru. [109.173.43.194]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53a223e58dasm790409e87.53.2024.10.22.07.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 07:47:14 -0700 (PDT) Date: Tue, 22 Oct 2024 17:47:11 +0300 From: Dmitry Kozlyuk To: Lewis Donzis Cc: dev Subject: Re: Including contigmem in core dumps Message-ID: <20241022174711.7862000d@sovereign> In-Reply-To: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> References: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 2024-10-22 07:41 (UTC-0500), Lewis Donzis: > I've been wondering why we exclude memory allocated by > eal_get_virtual_area() from core dumps? (More specifically, it calls > eal_mem_set_dump() to call madvise() to disable core dumps from the > allocated region.) > > On many occasions, when debugging after a crash, it would have been very > convenient to be able to see the contents of an mbuf or other object > allocated in contigmem space. And we often avoid using the rte memory > allocator just because of this. > > Is there any reason for this, or could it perhaps be a compile-time > configuration option not to call madvise()? The commit that originally added madvise() argued that dumping everything ended up in coredumps with "useless" data [non-mapped or unused pages]: http://git.dpdk.org/dpdk/commit/?id=d72e4042c5ebda7af81448b387af8218136402d0 Dumping mapped pages sounds reasonable in many cases. Not in all cases admittedly: - legacy memory mode mapping a lot of pages that are not (yet) used; - if packet data is confidential while the app is not. The option to dump or not can easily be a runtime one. The safe default however seems to be "off". In dynamic memory node (not FreeSBD, unfortunately) rte_mem_event_callback-register() may be used to call madvise(). Maybe DPDK should allow such callbacks in any mode and invoke them during initialization to make the above solution universal.