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 8AB1545BC8; Thu, 24 Oct 2024 22:54:25 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 24350434E6; Thu, 24 Oct 2024 22:54:25 +0200 (CEST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by mails.dpdk.org (Postfix) with ESMTP id F140F400EF for ; Thu, 24 Oct 2024 22:54:23 +0200 (CEST) Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-539eb97f26aso1415949e87.2 for ; Thu, 24 Oct 2024 13:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729803263; x=1730408063; 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=kc73BSJyQVzx8DWD5OSitNoJ2VyFm3e/e6eiTG7MG+w=; b=fPbTIu+RLgpHHCyovrxHhfq+jR7DaMw3j0XpOELKzd+g89LTAth5g/jX5w+Zncqq6i unwpVUQ6nuPnCNua5Dctv3/tk62vUXT5IyL8qUVJIIzs+CQOcEkZ61CfIQ4tOwfqDSuM TqaYpUGaJqz8TpTSs7KaSKsCHQgWabGj2GMKZGgil+ocs3WJxv+jSXyTSS7kECV3kPvB Ex0OpPYkfYiQYzNqPd+m6H0utngJeCZcJebZb+M6gR/kYL6cZpSK5sg54qaD74+mqgqV H/O2asWdrp0qBBy5LBGa1qbJ1m4D9pA1woBLfFcii0Y6woJAcQQqTVbGKuUnEhQXQOYD JdIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729803263; x=1730408063; 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=kc73BSJyQVzx8DWD5OSitNoJ2VyFm3e/e6eiTG7MG+w=; b=b5ZfBfJ6h49v2LhBY7tzegWl5ZY9pZpUwP3KYzyu3vgnj0qiPJsmHFwKRvDt4elu0K pzt59M6Wvra5Ypom6s7/0NKy/0DCn0CgYG719mMByeV5LVkMqnHSTttxHfxSqXuECe7F teK8QvjCApWnlEShxL6bE6s24Y8jmwgIle6gLhXsKu9a4VSBJngSojCn/zDpH8gO7/d0 YQbOHCz2BbMvf6OcToBlWcw3nA35IueuYkp/fMQNsgcqllyey+WUwsvEAHeCQEIAyWUo 4zTfJOYM7bxF5Wt6hmQs9kJhRM3BZQdyQ9dfffmxtUVjnrL0X7j4IPItjonK51lvlMwd ITHQ== X-Gm-Message-State: AOJu0YwJDuw6jDGpJk2lDKZ9oJBVv2LNxAUCISXKD1cAAiQspJKJObtE T9MsbzEKV5y7gWfewfmFRFu0SR6VbhmBsJOTBLcE67OX0+D12wZd X-Google-Smtp-Source: AGHT+IHhT3mSQcgOnGIdngoEXT+ElCWrVwrDsRMejxiffq6a2IlGc6ctAB5UiLC1YTdFFWGUuwsbuQ== X-Received: by 2002:a05:6512:239d:b0:535:6aa9:9868 with SMTP id 2adb3069b0e04-53b1a30bcfamr4947110e87.19.1729803263035; Thu, 24 Oct 2024 13:54:23 -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-53a223e5ac1sm1460294e87.39.2024.10.24.13.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2024 13:54:22 -0700 (PDT) Date: Thu, 24 Oct 2024 23:54:21 +0300 From: Dmitry Kozlyuk To: Stephen Hemminger Cc: dev@dpdk.org, Anatoly Burakov , Lewis Donzis Subject: Re: [PATCH] eal: support including mapped memory in core dump Message-ID: <20241024235421.5c1bd67e@sovereign> In-Reply-To: <20241024093814.779d86c7@hermes.local> References: <20241023231859.1323727-1-kozlyuk@bifit.com> <20241024093814.779d86c7@hermes.local> 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-24 09:38 (UTC-0700), Stephen Hemminger: > Having a process set a system global value like coredump_filter via an internal > call seems like a potential problem. What about other processes on the system? > It may not even be allowed if using a hardened kernel. > > I would prefer that madvise() be used, and document the required change to > coredump_filter. /proc/self/coredump_filter affects only the process and its children. madvise() done on hugepages will be ignored unless this bit is set. So this must be done, and it seems convenient to require no user interaction. If changing /proc/self/coredump_filter is disallowed, EAL startup will fail and the user will have to go the way you described. So the current solution: - is convenient for a typical case - is still usable in a hypothetical hardening case On FreeBSD, including hugepages in core dump will require a global setting. There I've been planning to go your way and have the user configure it, because it is impossible to restrict to one process.