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 346B745BC9; Fri, 25 Oct 2024 02:22:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CDDF74357E; Fri, 25 Oct 2024 02:22:17 +0200 (CEST) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by mails.dpdk.org (Postfix) with ESMTP id 8B50F4060C for ; Fri, 25 Oct 2024 02:22:16 +0200 (CEST) Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-53a097aa3daso1315230e87.1 for ; Thu, 24 Oct 2024 17:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729815736; x=1730420536; 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=mekcNpdZdb0vJT07WB+c9P5pPaU+kDvDTwPY66wHVd0=; b=ZCQP6xCjJmlTFgJFyw5u01xaVcsrdN7wE5+XURZo+rTIwOWfhwDwuWjTMHuoB+IpHZ vbOqdcZ70IvhLmAfsqqnGguPmjTpAQ9Ud/QXhgOGVAcTMVkrll9kuXhw4PNsklIGHE+D IZxNx6cSJcgdrsLbsBVLrkMB7eM4O61oC4bj4PbI8fezv1VB9VmkMUu/W/5v/pWS8+Ad 8ySEbUiiU+7vMkckkZuJZW/fTsRfyoflF6sT2yo+4phhhkGQHMc3T3Ln4RVryDARZoq+ D2pDVNQQLqYJu/LUXqiPnFYK+Ugmk9hUXBUIN7e9p0cio60UCOMiIko0PWRw9NOrUpe2 pDwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729815736; x=1730420536; 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=mekcNpdZdb0vJT07WB+c9P5pPaU+kDvDTwPY66wHVd0=; b=F0eFUeX+rq8bOxnOWT0ZcurWpHSALN5F2P3Mn7Mm/9vxXmx7Yk7uTSzmIRy+y2Wkc7 FqRqPGKEFUqUJ+i3iMox3dTvKOFTk01Z+FbYLLatQIK6HUsMzu2+BKdQCLDpkBRv2xBu Kq41m+LV/IQe4O0peszoAWhK5tt3zTo3/t62jZHKZk5aubeP3iv56pmmES8sVyGi2Qeu lDHgsAYT1IEiVVM+v2T/ViOocJ7QrsVu2yVR9JBRMSaVSnswt9kR+IG3XqMz/Qegr089 O9TKLGpUp5BSir/d93mhytY+yR1Q36iSCMTqZITAWKfLgJvtjjGX4wqcHMypzWBrXW0/ 3row== X-Gm-Message-State: AOJu0Yy1arF12rQm8APGxelg5xLcxMXJlIyMIY5Ew9ptYTNHwu1h0dRe kecrpYbx2ZLhe87YmyLPHZ3B+sOMI5zhMvVzXghtwwHwGQNgG5T1 X-Google-Smtp-Source: AGHT+IFprVosu/IYYZu4wh8QYaay71IFmo4STST5KQRmNCshMGzueEdbbB0pIZos1ihlvAHzE95vxw== X-Received: by 2002:a05:6512:31c1:b0:52b:de5b:1b30 with SMTP id 2adb3069b0e04-53b1a36196amr4607805e87.44.1729815735635; Thu, 24 Oct 2024 17:22: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-53b2e1ecc14sm6706e87.283.2024.10.24.17.22.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2024 17:22:13 -0700 (PDT) Date: Fri, 25 Oct 2024 03:22:12 +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: <20241025032212.6310eead@sovereign> In-Reply-To: <20241024235421.5c1bd67e@sovereign> References: <20241023231859.1323727-1-kozlyuk@bifit.com> <20241024093814.779d86c7@hermes.local> <20241024235421.5c1bd67e@sovereign> 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 23:54 (UTC+0300), Dmitry Kozlyuk: > 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. On the second thought, why block or enforce anything at startup; it is more flexible if we allow the user to enable dumping hugepages at whatever moment they wish, including prior to startup. This series would then become purely documentation for Linux and similar + a bit of code for FreeBSD.