Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3166340rwb; Mon, 15 Aug 2022 19:54:29 -0700 (PDT) X-Google-Smtp-Source: AA6agR43uRiacid3OYgGaUdzhAm8FlvJxZjaalPJV6VgvtFu4zpQFXzNWC2Lm0yo2AjiDKsCtQ5V X-Received: by 2002:a17:907:6091:b0:731:37fb:bd9 with SMTP id ht17-20020a170907609100b0073137fb0bd9mr11978902ejc.219.1660618459077; Mon, 15 Aug 2022 19:54:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660618459; cv=none; d=google.com; s=arc-20160816; b=gpfhKQlDN0qQjzOjifNMvc9nePIdjZztItnKZSZ/zcDM7sOMsGJTkJ9SrLb2w5Dsuq xYjuOkg6mij2k1NaOuWQQ68xho/X0QXSp/lM7tTJSQZgJeUjxcvNkQVyG19iiEBbgUZb u9bFWShwZN2YKNSxGbSNms2gErpi19C5fKqQ9GIpgjzhAeU7Iev5f3JnUZhr6MVi1Qdw kbqOZlxboSi0s00Cqud0fQk4xwPLzWa8VFvonA36AmrTbwelYsdBUooK3JKV70FaQLXP qjJFJuxlXTXW1OT34LS4htF99EXXUYNbgKUmHXN3+bryxroL8V3J0uU73r7CXoBi3OQ5 TxDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=bWWfdQ1fZAta1+VTRIUNVvKhFu0nb8tEZm/qx3ccvwQ=; b=L8ykhUWEaY5IoX6ZIa9u+aCwYKiTUjmLHiHgK7L0H0IuBT1O7mc2bqGGZAvVt4N1SZ MS9S9xErhten+yF5XyoopTgFgsH7o4qmGmo0PzIOb/VMFrh0ntPy8cih4EsiHKPmchGA EtvKTiLpQM58DBVLTLNg+CqA2aJWu8hg4g2V4Xx8k15SWWWA3QxvXcTuEU7m2cmRWi2D 3ew/cLEAUcgk5tZK+kdXN9XpN1upEyyeCTf4NnMYFLXmacuUtDdf/L+jQY6rVroVolj+ yLgVOuihxPheoHA/yh2NZuhCOmAIh/RiQcjJggfMLiW6PWZME5SfGGevD9a0r4l+v+R6 ZPFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gMMsNDgA; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hv10-20020a17090760ca00b0072b3df402efsi9156264ejc.124.2022.08.15.19.53.53; Mon, 15 Aug 2022 19:54:19 -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=@gmail.com header.s=20210112 header.b=gMMsNDgA; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233521AbiHPB7H (ORCPT + 99 others); Mon, 15 Aug 2022 21:59:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233454AbiHPB6l (ORCPT ); Mon, 15 Aug 2022 21:58:41 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 714F8106B2C; Mon, 15 Aug 2022 14:52:37 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id w19so15724789ejc.7; Mon, 15 Aug 2022 14:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=bWWfdQ1fZAta1+VTRIUNVvKhFu0nb8tEZm/qx3ccvwQ=; b=gMMsNDgAfR3K/kxdlQnHJVEHkeY6aMHWEOiekL+yQtlq1PV4ENY5ZVqeya+0hoGUEV XJraAAmxmMXvqsg0S5gzez+uweUIuY92YzrdO7TTZegDsIaUP1vEjPdvILtxoMZbytWo M2BnOqqKyT8sANIw6rCUUK8RKiQ2KuEPZZLwPI4D1HepWXtB8qWrr+gVtlBWkcC9YdLi joG2kl6qRIK3caOiIgi8Djyy9r12b+aGprexYd+aimOyvKzVAKVm+j/v4faS+u0x4RSe WpL8vospzU1l+kWdNrTbxopLCFMogim4YF03tJfAJQEwGC/MQsWKhXmHOPjQaHANvya2 yBtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=bWWfdQ1fZAta1+VTRIUNVvKhFu0nb8tEZm/qx3ccvwQ=; b=6yHhJDYjBR3G9IVnqt2zP3tmVGbXia3e7WEIhrmnMkcu63/2rFECrEwCw+fEnLHCLp ojI/kQxt+Nm5+QqPq/3bZrRV1c4qh0+qbXq6dngYWoJ5za7SKZR2BzKoAeJTldOc8f5G f0xIuv3d200h0SYMKY20r2gWAkpEtMsxTqDYjm68axpHh1QpuJHuKiQ3Fud5DshyRhGB GzwW4s5Kf294+OMRrRECPafU1ti927UYy06COu0W851i3vz0cJcNma2JDK7h5IXZljRt whmN3VbB4ZOz64684YjMcU/sdwfj421fxGkNWz2Z2w5mfvswSWju1Qsh7HCN8/oSwFDB dqLg== X-Gm-Message-State: ACgBeo05yjoAFXTT7VtFXUVqFjKt7G4ics7Wt0iwWpYbl6xKmUbYCWoe U01JkXg45I207TYG2sQWHopzSzF2K4kH/dqrfsE= X-Received: by 2002:a17:907:6e22:b0:731:152:2504 with SMTP id sd34-20020a1709076e2200b0073101522504mr11895143ejc.545.1660600353588; Mon, 15 Aug 2022 14:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20220810171702.74932-1-flaniel@linux.microsoft.com> <20220810171702.74932-2-flaniel@linux.microsoft.com> In-Reply-To: <20220810171702.74932-2-flaniel@linux.microsoft.com> From: Andrii Nakryiko Date: Mon, 15 Aug 2022 14:52:22 -0700 Message-ID: Subject: Re: [RFC PATCH v1 1/3] bpf: Make ring buffer overwritable. To: Francis Laniel 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 On Wed, Aug 10, 2022 at 10:18 AM Francis Laniel 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 full. > > 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. > 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. 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. > Signed-off-by: Francis Laniel > --- > include/uapi/linux/bpf.h | 3 +++ > kernel/bpf/ringbuf.c | 51 +++++++++++++++++++++++++++++++--------- > 2 files changed, 43 insertions(+), 11 deletions(-) > [...]