Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3657777pxb; Wed, 13 Oct 2021 10:14:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGD/beb6dpEJRJ/rVpu7ZQQWOLTOTn/StJ5DbbDRKWPOc4tuyWlym44bCh6//0nXG/z6az X-Received: by 2002:a05:6402:51d0:: with SMTP id r16mr791232edd.353.1634145273127; Wed, 13 Oct 2021 10:14:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634145273; cv=none; d=google.com; s=arc-20160816; b=pfyKd2mzeGQQJRiQCVKyUqFJ6NmG/KMzCF1StTWXJhDImCjchqbRqWsa5KYlqiESOG wKURUNu9B3yYAz8BiCoMMYLHuI+gVKbuW6DZ4UDws+20JXzLaISLi22PZ2FcYwYqyfhC AaKjLsuYtgezqL8dDd2/bZbPowAyTSRl/yuyZwAUpgNwaof7F/6fbBJJXegnj1UARzna 6D4kuNuRk1HWNzxHFPEAS0z1mWXne9yi6hVmRj+gYj6rNM0vwOU2TzBl6dB5C7/kkQ97 zanwReDc64IWvrDSGsjQIIkmKEBjvTBSNw/8s3AaDqLdjdtqDIuB0PFT0xEVBQrys9zw 6gtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=suxv0E7soYAWJnlQH9wyp2H4OVhoJs3o7rnYY0RGGLA=; b=X8sQnFmRkEyG7/r9ABklN11+by3A+AExRgZvAh5p9hZgaKmOGsnsVB/Fb3Q5RF1zON lbsBFsh95/Mwg+anfAu2ppyRMjBwp5jdp13Ck5p5BFN+NRHvLtbtUlO+l/UsC2CK+E5f oUOleFq8x2yssymiqXnuej7bnmRfmO7zrXuOempdh2xgvaDJlyJKWmRh8ZJL/DMPxdEO tBgYr9uKAANxEcIeGFNzh1xSaCQn3OginLhUxGl3Y97WMMO9H9arik1H5jNWPAWsmgGT xhRThkc+HN3dfcP70ChqcpRTh/UEDDh/d1eEPZKmMVr3gaDEiX597d+m3QTm0VtZ/GUF iCxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id di1si181618ejc.420.2021.10.13.10.14.07; Wed, 13 Oct 2021 10:14:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233283AbhJMROC (ORCPT + 99 others); Wed, 13 Oct 2021 13:14:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:32818 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229915AbhJMROC (ORCPT ); Wed, 13 Oct 2021 13:14:02 -0400 Received: from gandalf.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 1A589610EA; Wed, 13 Oct 2021 17:11:58 +0000 (UTC) Date: Wed, 13 Oct 2021 13:11:55 -0400 From: Steven Rostedt To: Beau Belgrave Cc: Masami Hiramatsu , linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events Message-ID: <20211013131155.69fa0e11@gandalf.local.home> In-Reply-To: <20211013165043.GA1427@kbox> References: <20211005224428.2551-1-beaub@linux.microsoft.com> <20211007012827.99cd5795140cbb0c932e1b5a@kernel.org> <20211006175611.GA2995@kbox> <20211007231738.0626e348322dc09e7ebbf1d6@kernel.org> <20211007162204.GA30947@kbox> <20211008081249.8fbacc4f5d9fa7cf2e488d21@kernel.org> <20211008000540.GA31220@kbox> <20211008182258.6bf272e6691679d41e7971fc@kernel.org> <20211011162523.GA1542@kbox> <20211012211852.2bbf921b@oasis.local.home> <20211013165043.GA1427@kbox> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Oct 2021 09:50:43 -0700 Beau Belgrave wrote: > > Does it require RCU synchronization as the updates only happen from > > user space. But is this for the writing of the event? You want a > > separate fd for each event to write to, instead of saying you have > > another interface to write and just pass the given id? > > > Yes, an example is a process creates the fd and registers some events. > Then the process forks and the child registers another event using the > same fd that was inherited. Well, I was thinking simple locking could work too. But I guess RCU is like Batman. You know, "Always be yourself. Unless you can be Batman, then always be Batman!". So always use locking, unless you can use RCU, then always use RCU. > > If the original process writes while the child process registers at that > point the FD array can get resized / moved, therefore we need RCU deref > protection when resizing, etc. > > I have a few gauntlet tools that try to crash user_events by writing, > registering, unregistering at weird times to try to flush this stuff > out. > > > In our own use case this will be low due to the way we plan to use the > > > events. However, I am not sure others will follow that :) > > > > I will say, whenever we say this will only have a "few", if it becomes > > useful, it will end up having many. > > > > -- Steve > Agree 100%, I've gone back and forth on which is better for a while. I'm > happy to update to RCU and send out a V3. Want to make sure we have > consensus of the right approach before spinning on it :) > Sure, thanks. -- Steve