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 2173EA0548; Tue, 17 Aug 2021 09:39:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E0F664014E; Tue, 17 Aug 2021 09:39:14 +0200 (CEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 22F6740143 for ; Tue, 17 Aug 2021 09:39:13 +0200 (CEST) Received: by mail-il1-f172.google.com with SMTP id v2so15050715ilg.12 for ; Tue, 17 Aug 2021 00:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OLTiYu2O022Zu4HiRcuwRR/x9Bt0nuNOAfwgdejmBOU=; b=ov/avMSrwkO+fNVnG4lFtIHZYUeZK+sI1euaNkhKFeSPkjgdcyXR+u2W2oFhNvHWzr BEVJ9rsTqjxnl7miBuL5OoAerUk2zc2FkbvrWhSuk09j9uyCvi7QUx3VekzLi+PWr7bx 7BzySVfcOEWsU1swmHd2zEl04+rHIibu9N5+BQEmzCyTpexT6ZGonKblAUfS4gTeYRJN c/DbMkqxwXkXvLE9zXwOHJE8lg114Hs5j4YsxFKQD+igCe/jNheFMm0+TONRLBfdJPLf GRiSpkJqDZR0aLPRLH4sLy+kI7sa/iBUx7q5dl/ez+tfjp8/HJoDyOf1161dpv7miP1w MKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OLTiYu2O022Zu4HiRcuwRR/x9Bt0nuNOAfwgdejmBOU=; b=FhYfbKa3Zk0X/dHa9XbpyJcCDYOvmSBsj18OLg3GRFkF0gKq/bgI0Famq/pQeKnjDp CcZ8CUeEam6gXsR0B9jPijGw6nuMCTMsdoyRhKkLIFYn4peBWGIFL90VX6JMLsgyzorB ERkTim7ABUVNLJo6rz0oQ/UeSR10e1Wwlfz3zsiHavSsCxAF8nnTqPdeJeqe+ku10LB/ 8gkXWJzPglJMely4noaYUHP72NjmfmhscTxs42WbYUke6vekx83jhwbwxj8ymRr/iuh8 1S/Rxs4lbPRYEI+rQmllUDvdYuHSnOOg4GgP1e3AdakzRYYwf4fds81k7d/GuV7PMbq8 Eq5w== X-Gm-Message-State: AOAM5338yCRmJGBvI5E6vHQSbSNwc/1RZPewM25BqVh6xTUJ1UJO6PzX aIiW9u+LW0q1HEcQVkqiL4Fk1dLjnV68Nht8dEM= X-Google-Smtp-Source: ABdhPJzpuLIP4viFFeKEBzar7WPBXuKZb8nFsY4HCfJIt75rAF4MlesnPFcbaBilvYA4YvbGzK57Q3Yr2fE4MJaWPIQ= X-Received: by 2002:a92:d70f:: with SMTP id m15mr1500259iln.162.1629185952510; Tue, 17 Aug 2021 00:39:12 -0700 (PDT) MIME-Version: 1.0 References: <20210730084938.2426128-2-jerinj@marvell.com> <20210817032723.3997054-1-jerinj@marvell.com> <20210817032723.3997054-2-jerinj@marvell.com> <20210816205345.6d686c7d@hermes.local> In-Reply-To: <20210816205345.6d686c7d@hermes.local> From: Jerin Jacob Date: Tue, 17 Aug 2021 13:08:46 +0530 Message-ID: To: Stephen Hemminger 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 Content-Type: text/plain; charset="UTF-8" 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, 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?