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 2348FA0548; Tue, 17 Aug 2021 17:09:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9E29A407FF; Tue, 17 Aug 2021 17:09:30 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id DC2194014E for ; Tue, 17 Aug 2021 17:09:28 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id n12so24523945plf.4 for ; Tue, 17 Aug 2021 08:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=qDKbsTgynBNXWLTZSGu7d2Lhgu9Un5u+gvssgW4svGk=; b=X+bQsRsw8qmWESvxbjJC5+ajWz6eCNsTPO+2YLBdn8oMGp8AO62ex3rvz2BdXS0urV H9Q7J69CDIWFzEklhwkC30Aj9IbZziV1NE1+Z3Z/gGMcD9nPz9JIepKSLhajuiW449xu 0K1R1fuBcQsi2TzSmW3yOn2btP22VaG4w44wxpIRI0fnwLRJwq+e+D3f3VVBlV690Q2B UcoYq2CLWt/coLxsX5QQUL3hG8EatriWtkJPCkNDoXvud4noDL8hExwFBPJGD7mvZgMF bvY8KwrdCyRVHH6IwxocDrgU7K4TEuTtgLvOXtPrT+dh2bhS2GUFbMsD8MxW/5wi/RyO eqvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=qDKbsTgynBNXWLTZSGu7d2Lhgu9Un5u+gvssgW4svGk=; b=UjfqHC2bSFTVKtbEtmuT8Mk9MbnOxAML9r1H96gREduoeKdUDUpeP3qAV3beCBOXMj 25/helcheNEOYl/cmXFjnKRoERv32hnu2BPspU2uFT4dhiaidKUO41oOHo0uqM81axj6 LZctuTuv9eIScnh4wRpu/FfSh08eavYcFPOHC1Sxy7YcZbDMGWEMKPq7vKfeZOU1cGoc lohyloz3Gh34+vR5uAFpscEefXYr9RGkkkvMYk9yEXXi+6EqUhcnAEor4J9qN6uy5XuG kDio8Z4xx2/QKdTEjL2pfaskmH2lfiCYz1cSBvX/8TinjoIoPPY28AeqI4+7Elaxoadh nB+g== X-Gm-Message-State: AOAM530aeVkPAdZVNkTXqcRsNK/88xU9ZkN5okfL7MSgfhq/G/FbA6RW rjHmQ7TnGZZHH0IvDWVMAd+/Yw== X-Google-Smtp-Source: ABdhPJx73k0IK5ghulA1/uelQ2eorjoEvPKtvxqQEZJGPE/iKYi7X7J6uBMhdBDAyaWJfdU9kttriQ== X-Received: by 2002:a17:90a:d595:: with SMTP id v21mr4196958pju.50.1629212968065; Tue, 17 Aug 2021 08:09:28 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id m18sm2573898pjq.32.2021.08.17.08.09.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 08:09:27 -0700 (PDT) Date: Tue, 17 Aug 2021 08:09:24 -0700 From: Stephen Hemminger To: Jerin Jacob Cc: Jerin Jacob , dpdk-dev , Bruce Richardson , Ray Kinsella , Thomas Monjalon , David Marchand , Dmitry Kozlyuk , Narcisa Ana Maria Vasile , "Dmitry Malloy (MESHCHANINOV)" , Pallavi Kadam , "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , Jan Viktorin , David Christensen Message-ID: <20210817080924.7049fa2d@hermes.local> In-Reply-To: References: <20210730084938.2426128-2-jerinj@marvell.com> <20210817032723.3997054-1-jerinj@marvell.com> <20210817032723.3997054-2-jerinj@marvell.com> <20210816205345.6d686c7d@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 1/6] eal: introduce oops handling API 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 Sender: "dev" On Tue, 17 Aug 2021 13:08:46 +0530 Jerin Jacob wrote: > On Tue, Aug 17, 2021 at 9:23 AM Stephen Hemminger > wrote: > > > > On Tue, 17 Aug 2021 08:57:18 +0530 > > wrote: > > > > > From: Jerin Jacob > > > > > > Introducing oops handling API with following specification > > > and enable stub implementation for Linux and FreeBSD. > > > > > > On rte_eal_init() invocation, the EAL library installs the > > > oops handler for the essential signals. > > > The rte_oops_signals_enabled() API provides the list > > > of signals the library installed by the EAL. > > > > This is a big change, and many applications already handle these > > signals themselves. Therefore adding this needs to be opt-in > > and not enabled by default. > > In order to avoid every application explicitly register this > sighandler and to cater to the > co-existing application-specific signal-hander usage. > The following design has been chosen. (It is mentioned in the commit log, > I will describe here for more clarity) > > Case 1: > a) The application installs the signal handler prior to rte_eal_init(). > b) Implementation stores the application-specific signal and replace a > signal handler as oops eal handler > c) when application/DPDK get the segfault, the default EAL oops > handler gets invoked > d) Then it dumps the EAL specific message, it calls the > application-specific signal handler > installed in step 1 by application. This avoids breaking any contract > with the application. > i.e Behavior is the same current EAL now. > That is the reason for not using SA_RESETHAND(which call SIG_DFL after > eal oops handler instead > application-specific handler) > > Case 2: > a) The application install the signal handler after rte_eal_init(), > b) EAL hander get replaced with application handle then the application can call > rte_oops_decode() to decode. > > In order to cater the above use case, rte_oops_signals_enabled() and > rte_oops_decode() > provided. > > Here we are not breaking any contract with the application. > Do you have concerns about this design? In our application as a service it is important not to do any backtrace in production. We rely on other infrastructure to process coredumps. This should be controlled enabled by a command line argument.