From patchwork Tue Dec 12 11:59:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 177284 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp7668730vqy; Tue, 12 Dec 2023 03:58:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IESKoKg/IKDHbP/A7Bh5Qs/w3ZQSEulpy0AiD3A43UkAK+ER0paXreKfvEq4TkXGSaj4nyp X-Received: by 2002:a05:6e02:1a23:b0:35d:9fd4:aa78 with SMTP id g3-20020a056e021a2300b0035d9fd4aa78mr9711254ile.14.1702382329417; Tue, 12 Dec 2023 03:58:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702382329; cv=none; d=google.com; s=arc-20160816; b=suMTiNrM+hfSAXHFGSE7hb9+4vWxPdxL3Hs3zeEJ35Zc9ajjGUWv41QkaevNPffv1Y Dg0abug1QxE8tMWTkTugu9fut6lQRDSkxTrnPaMRrB2Or5DsIGvN8J6GAcisBqd+gAa8 35tNX9yaGI3QPgnMItpQBrvWVMF23VNMtD8cxpJzK9XIDhLh5H+63E2LeS29HjtIInGG WMLzeS1D4g8KTZqtdhkbKPJDRyYLCnWeDWxeBqqsseditT2cguUTposMKUgZPxAKaahD o2LBDOVwJ4Zi8dgZ0N9y5aJp26yvYOPN/rJvBTukj5UI+LsYTZjSE+LpgJcK0+8rpNur IJPg== 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 :message-id:subject:cc:to:from:date; bh=AjMmUi5UrfGrAJ2DSKYblWB7MuBTpszrY4uPo9AHPMQ=; fh=9ZHKc6QFe4ebwFfm0H61cjjvXLY1pHPLv5pJGQloVEo=; b=0v3lATLdf9gAz2MfME8Rc09MRwLzthQOT4WxO17mTvHAX5vcMtyNWwh17tK3wEf3jy 6NkUwHIGf6kPF7CH1qH5xRsaH4Bt5cdvN8crEVy+2PauzGa2I9AgxA8vXpRDP4MwuFw7 Zg4NRl1NoF13S1j9jU8B6Lf1LWDwZ2tihYrmtRSJyFtHWluWQ2yvHcEcubhiFeRvL2+S CATivQSDgTBO1chszZ4Mx8c4Y2U9/vy+xWQuYZloCibEc6/TRJNF1yVHGSp8P8Uhk63Q 3SKFSPOeVklYUX3+WmKS3XJdXYNh81kRGVJydVdgZ7gj4yesKc/DkbAdOJGlyr/a/6wn 6G2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id u8-20020a63df08000000b005c5e2165e37si7859066pgg.125.2023.12.12.03.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 03:58:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id B3D7280C4D5F; Tue, 12 Dec 2023 03:58:45 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232217AbjLLL6g (ORCPT + 99 others); Tue, 12 Dec 2023 06:58:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229963AbjLLL6f (ORCPT ); Tue, 12 Dec 2023 06:58:35 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03876AF for ; Tue, 12 Dec 2023 03:58:42 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5096C433C8; Tue, 12 Dec 2023 11:58:40 +0000 (UTC) Date: Tue, 12 Dec 2023 06:59:22 -0500 From: Steven Rostedt To: LKML , Linux Trace Kernel Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Kent Overstreet Subject: [PATCH v2] ring-buffer: Fix writing to the buffer with max_data_size Message-ID: <20231212065922.05f28041@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 12 Dec 2023 03:58:45 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785077253871262819 X-GMAIL-MSGID: 1785077253871262819 From: "Steven Rostedt (Google)" The maximum ring buffer data size is the maximum size of data that can be recorded on the ring buffer. Events must be smaller than the sub buffer data size minus any meta data. This size is checked before trying to allocate from the ring buffer because the allocation assumes that the size will fit on the sub buffer. The maximum size was calculated as the size of a sub buffer page (which is currently PAGE_SIZE minus the sub buffer header) minus the size of the meta data of an individual event. But it missed the possible adding of a time stamp for events that are added long enough apart that the event meta data can't hold the time delta. When an event is added that is greater than the current BUF_MAX_DATA_SIZE minus the size of a time stamp, but still less than or equal to BUF_MAX_DATA_SIZE, the ring buffer would go into an infinite loop, looking for a page that can hold the event. Luckily, there's a check for this loop and after 1000 iterations and a warning is emitted and the ring buffer is disabled. But this should never happen. This can happen when a large event is added first, or after a long period where an absolute timestamp is prefixed to the event, increasing its size by 8 bytes. This passes the check and then goes into the algorithm that causes the infinite loop. For events that are the first event on the sub-buffer, it does not need to add a timestamp, because the sub-buffer itself contains an absolute timestamp, and adding one is redundant. The fix is to check if the event is to be the first event on the sub-buffer, and if it is, then do not add a timestamp. Also, if the buffer has "time_stamp_abs" set, then also check if the length plus the timestamp is greater than the BUF_MAX_DATA_SIZE. Cc: stable@vger.kernel.org Fixes: a4543a2fa9ef3 ("ring-buffer: Get timestamp after event is allocated") Reported-by: Kent Overstreet # (on IRC) Signed-off-by: Steven Rostedt (Google) --- Changes since v1: https://lore.kernel.org/linux-trace-kernel/20231209170139.33c1b452@gandalf.local.home - Instead of subtracting the timestamp size from the max data, check if the event is the fist event on the sub-buffer and if it is do not add a timestamp. - If the ring buffer enabled adding timestamps for every event, then check if the added timestamp puts the length over BUF_MAX_DATA_SIZE. kernel/trace/ring_buffer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 8d2a4f00eca9..d8ce1dc5110e 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3584,7 +3584,7 @@ __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer, info->length += RB_LEN_TIME_EXTEND; } else { info->delta = info->ts - info->after; - if (unlikely(test_time_stamp(info->delta))) { + if (w && unlikely(test_time_stamp(info->delta))) { info->add_timestamp |= RB_ADD_STAMP_EXTEND; info->length += RB_LEN_TIME_EXTEND; } @@ -3737,6 +3737,8 @@ rb_reserve_next_event(struct trace_buffer *buffer, if (ring_buffer_time_stamp_abs(cpu_buffer->buffer)) { add_ts_default = RB_ADD_STAMP_ABSOLUTE; info.length += RB_LEN_TIME_EXTEND; + if (info.length > BUF_MAX_DATA_SIZE) + goto out_fail; } else { add_ts_default = RB_ADD_STAMP_NONE; }