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 14A35A0548; Tue, 17 Aug 2021 17:28:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E31041103; Tue, 17 Aug 2021 17:28:18 +0200 (CEST) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by mails.dpdk.org (Postfix) with ESMTP id 18C1540DF5 for ; Tue, 17 Aug 2021 17:28:17 +0200 (CEST) Received: by mail-il1-f173.google.com with SMTP id h29so6060312ila.2 for ; Tue, 17 Aug 2021 08:28:17 -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=fK+JVc+cAAeF5GFPVSx1pF++SUfpHF3KzsprGxew/2o=; b=D6wkGIqFotNqCEcmlAzcxEzLvno1//r5uPAZjorEgmQJ3O7YnXtSTExgRJ/17uMrye AoDBLtBw0DL70fcz8+UqASysPc/X89XxNjxAWPEv9mAIzN+Q4QKJWBeCn/3ynomNbcd/ CYOPIyDMweUqH+sTzbSf7N1X0e4oxS+8rzbvwxdsOYrMywvJU7wHXyrTqT7RRy7OHn9o GjrXYf9AAoQsBqA1J54c1gwXig6O4guMV9ehXRZktcKjnpUx0yvL7jTUBDTEfpypSlx8 k9hEkHWN38YEYUrFQcOUO1S0cihr3Y/y9d2xooyCNuv0TStOfRK1p8qHElaW58aIRoBM X1gg== 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=fK+JVc+cAAeF5GFPVSx1pF++SUfpHF3KzsprGxew/2o=; b=o7xTqcrYC6f+lLXA2J+5Xz5v298kqVzdfbm6IBCDOCom1d6bpp+ebpw+kWCu5K1eJ4 yrjHFhbDTs39zDdYuOScR7YAmBx82N3Q95ASZaMVmx6zNGhOGuMJzFTxcZKhm/k/tXp7 735fuhFIdYShYGjZisflVm32IPepgVWTse4vpgJ6H4vhJv0MMWDURw3zjF5KKKlb6ky3 d/9RSWu/Kqi2Q2oa4jzCDZo2AHAA0hz/LZwG7U28Vjmy7rACnbPQTDDYAuTxXtRq0/8W OKEaFe0GhWP+nYfcWmIFSj8q8zaKmYJD8f6CHb4t6fPqo0O2Wtyy3jr5fgRUDmavTDj9 tCJQ== X-Gm-Message-State: AOAM533kaEg7lYgRv7MTK10P4uarB+94dGvaKDivRsCgcgs6Z4txxitB 80eVzPQxHXPWlKuWSLHkp43tvRUyIonDCuARFAM= X-Google-Smtp-Source: ABdhPJzxuTcZVXWQ8Nb31bRevsvWw/g6paITayEE4D+gq8ypsJ8r0B1/YNHQhZzct83XZDdFDwOYoJs4NpI5+GPi48Q= X-Received: by 2002:a92:a012:: with SMTP id e18mr2634286ili.271.1629214096397; Tue, 17 Aug 2021 08:28:16 -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> <20210817080924.7049fa2d@hermes.local> In-Reply-To: <20210817080924.7049fa2d@hermes.local> From: Jerin Jacob Date: Tue, 17 Aug 2021 20:57:50 +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 8:39 PM Stephen Hemminger wrote: > > 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. Other infrastructure will work. For example, If we are using standard coredump using linux infra. In Current implementation, - EAL handler dump the DPDK OOPS like kernel on stderr - Implementation calls SIG_DFL in eal oops handler - The above step creates the coredump or re-directs any other infrastructure you are using for coredump. > > This should be controlled enabled by a command line argument. If we allow other infrastructure coredump to work as-is, why enable/disable required from eal?