Received: by 10.213.65.68 with SMTP id h4csp197307imn; Fri, 30 Mar 2018 03:54:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx48EHBB24AWPVQheqtrdlzpNlVvkOcvdIREMMWYvLIAbqT+oICxeRMcOkz/YJn+ivUJLtF1p X-Received: by 2002:a17:902:3341:: with SMTP id a59-v6mr12521294plc.68.1522407279911; Fri, 30 Mar 2018 03:54:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522407279; cv=none; d=google.com; s=arc-20160816; b=ITcQhjxA4NbtvrR8zsFHfUjiqsr1/cBx2BUzWnziFf3RrBVYzqmpuH+U0KZrPlmUrN yR4jYUyzkAMkI3OIkJd1A92LfMm+6yvSzGwqevueepQyy21wqBaTbxjHglBCJwNGTpb+ msYp+joYAK1JVCt8mpYckJ75vRBeI+eoj1AAv0FMLiZDJMKhvq4pzwdDBRzBYr8WiDTc 0A2202BcJOcbI6tkNyK8ibI3s5inp9fk5pYnvkgLGOuM/RPPL7JcwY2ERs+JnovUQrP4 KKvunKkytH2885E1H9pSWdXpxrJsKDTHTahXz8aMY4pppsXE7dCjLm2Sx/1f0G0mXAjp sOwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=6ufAXMdHBeJ1zGjz4pkD4U2QJgmJC7Xt1cTpDO9VOmk=; b=FZHjU9rVZb/xTSoYcYJRBRlZMR4Aytf+0Con5qlC3QBnk5Wkk2PV/2GKWZ5F4ez1Dh hXsm+7rOLYtkEHvoKz7o0tjX+bP456hF+nPhIjHKR0PPAgHKBgmnHy1i1xIGD0tt9DcU zzGEjI49SdJyeX99ZKqqTiF/kAW2qTiph1M4nJK7ZkF2NpVrIATAFOYu0b/LYx3ZxPyC DD1j8ZJDd4PCuHZO4pQI9RzDdRbeuib4lsCZkr9ANGB1dw35OplsOplHcDbV7g9sbp40 D3MhGWCX/ChXxbM2mBiUB5d9k0934jaRIdDSUdD5/+Y5MIZSUTM8oLQjyQbt8CR/RIrj T+2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3si3463993pfa.66.2018.03.30.03.54.25; Fri, 30 Mar 2018 03:54:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751251AbeC3KxS (ORCPT + 99 others); Fri, 30 Mar 2018 06:53:18 -0400 Received: from stargate.chelsio.com ([12.32.117.8]:54713 "EHLO stargate.chelsio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbeC3KxQ (ORCPT ); Fri, 30 Mar 2018 06:53:16 -0400 Received: from localhost (scalar.blr.asicdesigners.com [10.193.185.94]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id w2UAqk2W027269; Fri, 30 Mar 2018 03:52:53 -0700 Date: Fri, 30 Mar 2018 16:21:57 +0530 From: Rahul Lakkireddy To: Jiri Pirko Cc: "netdev@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "davem@davemloft.net" , "viro@zeniv.linux.org.uk" , "ebiederm@xmission.com" , "stephen@networkplumber.org" , "akpm@linux-foundation.org" , "torvalds@linux-foundation.org" , Ganesh GR , Nirranjan Kirubaharan , Indranil Choudhury Subject: Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel Message-ID: <20180330105156.GA24344@chelsio.com> References: <296ffbd47fd4f30238689e636bd2480683224227.1521888444.git.rahul.lakkireddy@chelsio.com> <20180330103907.GC3313@nanopsycho> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180330103907.GC3313@nanopsycho> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote: > Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkireddy@chelsio.com wrote: > >Add a new module crashdd that exports the /sys/kernel/crashdd/ > >directory in second kernel, containing collected hardware/firmware > >dumps. > > > >The sequence of actions done by device drivers to append their device > >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are > >as follows: > > > >1. During probe (before hardware is initialized), device drivers > >register to the crashdd module (via crashdd_add_dump()), with > >callback function, along with buffer size and log name needed for > >firmware/hardware log collection. > > > >2. Crashdd creates a driver's directory under > >/sys/kernel/crashdd/. Then, it allocates the buffer with > > This smells. I need to identify the exact ASIC instance that produced > the dump. To identify by driver name does not help me if I have multiple > instances of the same driver. This looks wrong to me. This looks like > a job for devlink where you have 1 devlink instance per 1 ASIC instance. > > Please see: > http://patchwork.ozlabs.org/project/netdev/list/?series=36524 > > I bevieve that the solution in the patchset could be used for > your usecase too. > > The sysfs approach proposed here had been dropped in favour exporting the dumps as ELF notes in /proc/vmcore. Will be posting the new patches soon. > >requested size and invokes the device driver's registered callback > >function. > > > >3. Device driver collects all hardware/firmware logs into the buffer > >and returns control back to crashdd. > > > >4. Crashdd exposes the buffer as a binary file via > >/sys/kernel/crashdd//. > >