Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3479413rwb; Tue, 16 Aug 2022 03:58:17 -0700 (PDT) X-Google-Smtp-Source: AA6agR45IABrwg/XlRyFY19t+4G6owfK3ZzRG+Bei2IGdrqO4z+Dr7R46WqIQAb9FxFBzMhcFKDQ X-Received: by 2002:a17:902:cec4:b0:16f:8fdc:954d with SMTP id d4-20020a170902cec400b0016f8fdc954dmr21849957plg.37.1660647497401; Tue, 16 Aug 2022 03:58:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660647497; cv=none; d=google.com; s=arc-20160816; b=xtQCqrC90etlkW7hOk9+b8qy2QTpvvrqAPtC+6mkiav/hCXeFZPJlHd9gyrxb99z9A tC3GDYG/U9YBoyG48o85V4kRB54gDFdyRoyniETropIYyNKEiksy5YAI+R/E4iIEkPuZ R2NYeFAuBtwb3zrZ6mtz9GKYdUScvCkPWG4UPK7ItTFSQYDt6r08YCfveh7DExGyAPm7 kqbgvztcP2GbEnXO3cfvH13ZsxhQsUJLU0YYrToFR4YkGuI2MLxdSgSHvOy6L9y7zVZP C3yYAYjcTkYu/Ye6eB+FsbvF6QSjbQxtV7drLAHJzWL2zC3o1eULSVCFdDgIRoOOfHcS A+RA== 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:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=YfkkOGSQxA2OzjWDewpNMpQo+oxj7eu+1OSnrSeEK4Y=; b=qirGmwy4Az+9E5V/QbaqnvI7jG0v5JxbU9xI3XcMgdGs40yXwNKssXEcFqBAzDLjpe 0TKDfGa7tfnkeI82WwSgNxSOndhSHhWZ5Oa3l/6bbhfQ9aDfGw+nbhrwmpAw8ZBLTeSx rQkPipPJP0Iofp3s/ao8jMfgRZDro1s5nNrY56Hj3OI+fkL0bmSBekiAXdKhadNsQ9SB u552Jc4dzOj8Y8XpOxNUvA3hPrr+exdMS7nSKBsFeatUq3OLlKFEgWA2xU+igkdFvH7J uH3WKQCQE+ZG5OYyuCxPmzFxv7eLBVFyhGGFQXjKHC0MlFN7lVLNpDBmMMMtQGiCFBjr /k5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=cmrKoiJe; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k133-20020a636f8b000000b0041b67131e27si13167759pgc.309.2022.08.16.03.58.05; Tue, 16 Aug 2022 03:58:17 -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; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=cmrKoiJe; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233504AbiHPKv4 (ORCPT + 99 others); Tue, 16 Aug 2022 06:51:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233821AbiHPKvg (ORCPT ); Tue, 16 Aug 2022 06:51:36 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C7FC47EFD2; Tue, 16 Aug 2022 03:23:47 -0700 (PDT) Received: from pwmachine.localnet (85-170-37-153.rev.numericable.fr [85.170.37.153]) by linux.microsoft.com (Postfix) with ESMTPSA id 08AD8210DA5E; Tue, 16 Aug 2022 03:23:43 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 08AD8210DA5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1660645427; bh=YfkkOGSQxA2OzjWDewpNMpQo+oxj7eu+1OSnrSeEK4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cmrKoiJeQ8xbvJW9ziVMLBaonuTZpJk6d2MfbsVZv0S9trKuNx1i/J1TAv0fcuPTo C6PRgeNl7F48RhkKDnG/hStuNX33PpJcL1UnY9jIVFShckPYpDhF4TyjCNgbFokBOd yHHrU4m7su454KWkXbuqn2UydG56HtdOEBjcnUUI= From: Francis Laniel To: Andrii Nakryiko Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Joanne Koong , Dave Marchevsky , Lorenzo Bianconi , Geliang Tang , Hengqi Chen Subject: Re: [RFC PATCH v1 1/3] bpf: Make ring buffer overwritable. Date: Tue, 16 Aug 2022 12:23:41 +0200 Message-ID: <1735233.VLH7GnMWUR@pwmachine> In-Reply-To: References: <20220810171702.74932-1-flaniel@linux.microsoft.com> <20220810171702.74932-2-flaniel@linux.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham 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 Hi. Le lundi 15 ao=FBt 2022, 23:52:22 CEST Andrii Nakryiko a =E9crit : > On Wed, Aug 10, 2022 at 10:18 AM Francis Laniel >=20 > wrote: > > By default, BPF ring buffer are size bounded, when producers already > > filled the buffer, they need to wait for the consumer to get those data > > before adding new ones. > > In terms of API, bpf_ringbuf_reserve() returns NULL if the buffer is fu= ll. > >=20 > > This patch permits making BPF ring buffer overwritable. > > When producers already wrote as many data as the buffer size, they will > > begin to over write existing data, so the oldest will be replaced. > > As a result, bpf_ringbuf_reserve() never returns NULL. >=20 > Part of BPF ringbuf record (first 8 bytes) stores information like > record size and offset in pages to the beginning of ringbuf map > metadata. This is used by consumer to know how much data belongs to > data record, but also for making sure that > bpf_ringbuf_reserve()/bpf_ringbuf_submit() work correctly and don't > corrupt kernel memory. >=20 > If we simply allow overwriting this information (and no, spinlock > doesn't protect from that, you can have multiple producers writing to > different parts of ringbuf data area in parallel after "reserving" > their respective records), it completely breaks any sort of > correctness, both for user-space consumer and kernel-side producers. Thank you for your answer. My current implementation is indeed wrong as I based it on the wrong=20 assumption than BPF ring buffer could only store data of the same size... With data of different size, we can have the troubles you described. I will rework my patches and send a new version once polished but I=20 cannot give an ETA. > > Signed-off-by: Francis Laniel > > --- > >=20 > > include/uapi/linux/bpf.h | 3 +++ > > kernel/bpf/ringbuf.c | 51 +++++++++++++++++++++++++++++++--------- > > 2 files changed, 43 insertions(+), 11 deletions(-) >=20 > [...] Best regards.