Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp294899ybg; Tue, 22 Oct 2019 21:00:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqxC2A94vZjbhlXUOGTxe23XgI37+kbglaOUTv1WWvQsk3OMc80uimeuXnXqa6GxzgGRWGzj X-Received: by 2002:aa7:cd43:: with SMTP id v3mr34398664edw.235.1571803210767; Tue, 22 Oct 2019 21:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571803210; cv=none; d=google.com; s=arc-20160816; b=uysJeyqLtDUOib7lVShTWRMOuRhSf8/r0TYZSvL1SS+Cmugi5hW2EDKU8AdObL1nln 7pvHYpsd1Wn/qH2i64BZqroyVo4y09ShiAm9521ffWg2ea627hMiv5sVqlEIKX0dITzM nGlgkRX0keHTvIWIBqy1Ge1oC5OAJJ4bc7NoX8Cu7B93t3Zifu+9ZsGKCCwkpE0TKulp AYrFtYtiojNlsardF3btm3qeal6q+bsY/jE1iqEGIs1i3+19Cd/G9msXCpptyXNndKt3 36hRfvBvPH5+dFZP2x1pMjs64MgNcdmzp6KMhl3Ge643nj9Uda2SbQFmyoxmA5NrQWuI JFRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=e0ePJM9x1P4LH19xbgHsPG7E5aqRunNXdKQGcens/yg=; b=tQl0Vq2lgnXFe86KJs4SPXf+VzyYblfZgeqCoz94hCd1r3Y14AQpkRUVwIzNTQavsM oMKox0z/xvji5yNMmObm89Msx63/Y9sPpq7fe4EA5q/ZvwJ40FHE1pXIot67WX09XcD4 yfMjhHFP/J4esD6rvCT2JEEVZ1gPjKgExQ8gSof9bkAqDbNu9q/1FSSC4XTDAfJKDKGn HgQTUZDEArzAgwmqcW3ST6NztPuGqzXXRjtv6zdGZrTaAXik+XBXJnEEXz9f2fNbs/A4 737MkHwwRa9wmQInCQAq5SZfF/D+3N0c3Ld5VXkhoLUH079glFIkXegOmdRTLVDyUQFN u3Nw== 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 ss13si2561235ejb.259.2019.10.22.20.59.46; Tue, 22 Oct 2019 21:00:10 -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 S2389405AbfJWCw4 (ORCPT + 99 others); Tue, 22 Oct 2019 22:52:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:44008 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389377AbfJWCw4 (ORCPT ); Tue, 22 Oct 2019 22:52:56 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4E0BF2086D; Wed, 23 Oct 2019 02:52:55 +0000 (UTC) Date: Tue, 22 Oct 2019 22:52:53 -0400 From: Steven Rostedt To: Divya Indi Cc: linux-kernel@vger.kernel.org, Joe Jin , Srinivas Eeda , Aruna Ramakrishna Subject: Re: [PATCH 4/5] tracing: Handle the trace array ref counter in new functions Message-ID: <20191022225253.4086195c@oasis.local.home> In-Reply-To: <4cad186e-ba8b-8e1a-731b-4350a095ba5a@oracle.com> References: <1565805327-579-1-git-send-email-divya.indi@oracle.com> <1565805327-579-5-git-send-email-divya.indi@oracle.com> <20191015190436.65c8c7a3@gandalf.local.home> <4cad186e-ba8b-8e1a-731b-4350a095ba5a@oracle.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Oct 2019 16:42:02 -0700 Divya Indi wrote: > Hi Steve, > > Thanks again for taking the time to review and providing feedback. Please find my comments inline. > > On 10/15/19 4:04 PM, Steven Rostedt wrote: > > Sorry for taking so long to getting to these patches. > > > > On Wed, 14 Aug 2019 10:55:26 -0700 > > Divya Indi wrote: > > > >> For functions returning a trace array Eg: trace_array_create(), we need to > >> increment the reference counter associated with the trace array to ensure it > >> does not get freed when in use. > >> > >> Once we are done using the trace array, we need to call > >> trace_array_put() to make sure we are not holding a reference to it > >> anymore and the instance/trace array can be removed when required. > > I think it would be more in line with other parts of the kernel if we > > don't need to do the trace_array_put() before calling > > trace_array_destroy(). > > The reason we went with this approach is > > instance_mkdir - ref_ctr = 0 // Does not return a trace array ptr. > trace_array_create - ref_ctr = 1 // Since this returns a trace array ptr. > trace_array_lookup - ref_ctr = 1 // Since this returns a trace array ptr. > > if we make trace_array_destroy to expect ref_ctr to be 1, we risk destroying the trace array while in use. > > We could make it - > > instance_mkdir - ref_ctr = 1 > trace_array_create - ref_ctr = 2 > trace_array_lookup - ref_ctr = 2+ // depending on no of lookups > > but, we'd still need the trace_array_put() (?) > > We can also have one function doing create (if does not exist) or lookup (if exists), but that would require > some redundant code since instance_mkdir needs to return -EXIST when a trace array already exists. > > Let me know your thoughts on this. > Can't we just move the trace_array_put() in the instance_rmdir()? static int instance_rmdir(const char *name) { struct trace_array *tr; int ret; mutex_lock(&event_mutex); mutex_lock(&trace_types_lock); ret = -ENODEV; list_for_each_entry(tr, &ftrace_trace_arrays, list) { if (tr->name && strcmp(tr->name, name) == 0) { __trace_array_put(tr); ret = __remove_instance(tr); if (ret) tr->ref++; break; } } mutex_unlock(&trace_types_lock); mutex_unlock(&event_mutex); return ret; } -- Steve