Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp596134rwl; Wed, 29 Mar 2023 06:13:30 -0700 (PDT) X-Google-Smtp-Source: AKy350bPo7j00KtJXKLA82w+asFoSZSodyfk7vhWb+/RZDLicbSzujT79ebaqJJlmujsIy+DkiEH X-Received: by 2002:a17:907:2c46:b0:879:ab3:93d1 with SMTP id hf6-20020a1709072c4600b008790ab393d1mr22055253ejc.4.1680095610074; Wed, 29 Mar 2023 06:13:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680095610; cv=none; d=google.com; s=arc-20160816; b=Zq374CBec3isIobASmX947uwPP2UTo5vAXBDExq0cNVBSRRqTW+O3v3uyPBpfyetnp 4TwaoxaJ5M8Lw5SPhzqCBv3mpitGssZE3vQqZ32OD1ZkHBLPTGKkQzN4LGk1G+tiK1PH 6frOC2LZF3YDnsRh0w8HUnd0eOad1tc/zwG2vASpC5L7KtD18Kputj59vZbvFUrIBOwj eITCjMNEfl9hzyQNTe1C392zKhcS4EHODv2HCfV11ZAt7cppxWYXo9KVbPc1+kcEOw/H /nAt0Bk2ILjqdnkTzGJRTnizkyD5lumg69FSDkU6bXks9qb9+XGleIumFje5qq+yLnxx qxRA== 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=J7cyM5bORh+JC7m0LUlv78fkk8PXtjd1FVXlr5O95d4=; b=Oj7BCAPKnmBTHltHxhdGsEEhkfgrfaUZnG70ogdf1Cjox2vXmPiDsUF7Lz97ESJ0Ji lwpd8TpKxnfol1E7Jw1ryYBHjq+awNju7g5UO8S0fMHSvyIUtKRx2yI+obvvu17PP59/ wUvnaHpRemXYI2223dbc30IDB9HI1ksSpmFgrUhJribnS6Tu5dQ9WwT8uTY63ULX+fJT 1ThpGk1Ijg6/y9CU1OyPvdkG2jD8wtrd3VMwRzO4nG9rBT8JVEhBuNgPvAwfxiIJt8r5 D4YAljXsqwrINrHmEEGBoJPXSm8/f1sSCsOePYOxecIIa1PdZ/1LxiiSph0IiYr8FJwM 6tfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qw30-20020a1709066a1e00b0093404ccdb7dsi29421304ejc.861.2023.03.29.06.13.05; Wed, 29 Mar 2023 06:13:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230073AbjC2NLY (ORCPT + 99 others); Wed, 29 Mar 2023 09:11:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230099AbjC2NLV (ORCPT ); Wed, 29 Mar 2023 09:11:21 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DF3C4C33; Wed, 29 Mar 2023 06:11:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A927561CEB; Wed, 29 Mar 2023 13:11:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24174C433EF; Wed, 29 Mar 2023 13:11:16 +0000 (UTC) Date: Wed, 29 Mar 2023 09:11:07 -0400 From: Steven Rostedt To: Vincent Donnefort Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v2 1/2] ring-buffer: Introducing ring-buffer mapping functions Message-ID: <20230329091107.408d63a8@rorschach.local.home> In-Reply-To: References: <20230322102244.3239740-1-vdonnefort@google.com> <20230322102244.3239740-2-vdonnefort@google.com> <20230328224411.0d69e272@gandalf.local.home> <20230329070353.1e1b443b@gandalf.local.home> <20230329085106.046a8991@rorschach.local.home> 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 X-Spam-Status: No, score=-4.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Mar 2023 14:01:01 +0100 Vincent Donnefort wrote: > > Oh, I guess we should also expose the amount read on the reader page, > > that gets updated on the ioctl. That is, if the first time we read the > > reader page and the page is not full and unmap the pages, and then new > > events were added to the reader page, we should not re-read the events > > that were read previously. > > > > That is, expose cpu_buffer->reader_page->read > > Couldn't it be an issue of updating cpu_buffer->reader_page->read during the > ioctl? I guess we would write the value of the current written events on that > page, hopping for the userspace reader to read it all. > > But then if new events are written, the reader doesn't need the ioctl to read > them, it can just check the meta->entries field or the commit field in the > reader_page header? > > So it's much likely cpu_buffer->reader_page->read will go out of sync? Here's the issue I found during testing: write 10 events to ring buffer (all go into the reader page) Run application that maps the pages, and reads the 10 events, and exits. Write 10 more events to ring buffer (all are appended to the reader page) Run application that maps the pages and reads 20 events, and exits. It read the 10 previous events, but should not have. It should have only read the last 10 that were not read previously. -- Steve