From patchwork Tue Dec 12 16:16:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 177433 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp7832358vqy; Tue, 12 Dec 2023 08:15:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IHIakyzGPvdsesFBYomDH9H9foG84DHn/SSn4a0HSueCeI+GQGnoQVDJiqrFbfW1uW8TI+0 X-Received: by 2002:a17:903:1c4:b0:1d0:969b:4bdf with SMTP id e4-20020a17090301c400b001d0969b4bdfmr2934217plh.108.1702397752592; Tue, 12 Dec 2023 08:15:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702397752; cv=none; d=google.com; s=arc-20160816; b=x0VquiAyruz7V7FBD9Ief0WSjfrmZu4KCCoVm/4wKou8aEV85X1xgeOHCCG8Lt+PZw 5V0n3rI34/ZAafOXO3p3e9JmE0jWyfa8LZ2l9NbpbK8n3mILoZ0s5f22ZNBYmPLr+/XX R9QkVzZBn4+OMQCMccLJqNVH+fwDFcHtQySMZZB5tuudbngWsb+ATlPUmvTbIxxtIxaX v7TCg8XJw0pk1I3r0YEGe/Og3Hd8ezIjWszZ6ZrBPuRH21GRP0WX4sdmBo8UGqugG8io L8XS7cOB4Na19eRCXqjpb89EtGgzlQuu6TnGJNBWitCRh2g/zP8WVizp+WNarO9Y3Ggi cCKw== 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=BFGr0vSWEQx84gAe3jJwMgwYyleTVaSa6KteTttKh+c=; fh=9ZHKc6QFe4ebwFfm0H61cjjvXLY1pHPLv5pJGQloVEo=; b=spAH5lmING4hm0360P+CYuOI79uPUXM+ShCT5Osi+XqXk7gnthnLCvA/OGVsc0lSY0 p0AEvFhzK34DdpVkOHc/ciHaIl5QnZWPx3c2zWsA9yL+9PToYeQcLvf/BCU54pr8duPt hP6rAi1Y3H4Np++mZWKjiaM74h052foeKqxTvYGVqvRRH7UyU5hh0W0R/GGiVw1PdXaK h8egewmUCEI9UirQ09ZvVZtXwVuhV5brYyfpsNVW8IvXfkIGaOEh+hUMTFlo/Raf5s4O Vi3/XVElsw5UR4Gz6NZ56S84BbpXkWBDGJQ5wT0x9vveMZK6NzkeirUZEcTbmTRlSMPm SZ4g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id bx22-20020a056a02051600b005b909e678dfsi8077675pgb.450.2023.12.12.08.15.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 08:15:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (Postfix) with ESMTP id C291E807756A; Tue, 12 Dec 2023 08:15:39 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232529AbjLLQPa (ORCPT + 99 others); Tue, 12 Dec 2023 11:15:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232516AbjLLQPa (ORCPT ); Tue, 12 Dec 2023 11:15:30 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BC27AD for ; Tue, 12 Dec 2023 08:15:36 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04015C433C7; Tue, 12 Dec 2023 16:15:34 +0000 (UTC) Date: Tue, 12 Dec 2023 11:16:17 -0500 From: Steven Rostedt To: LKML , Linux Trace Kernel Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Kent Overstreet Subject: [PATCH v3] ring-buffer: Fix writing to the buffer with max_data_size Message-ID: <20231212111617.39e02849@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=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 12 Dec 2023 08:15:39 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785077253871262819 X-GMAIL-MSGID: 1785093426048984462 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. This also fixes 32 bit adding a timestamp when a read of before_stamp or write_stamp is interrupted. There's still no need to add that timestamp if the event is going to be the first event on the sub buffer. 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. Link: https://lore.kernel.org/all/20231212104549.58863438@gandalf.local.home/ Link: https://lore.kernel.org/linux-trace-kernel/20231212071837.5fdd6c13@gandalf.local.home Cc: stable@vger.kernel.org Fixes: a4543a2fa9ef3 ("ring-buffer: Get timestamp after event is allocated") Fixes: 58fbc3c63275c ("ring-buffer: Consolidate add_timestamp to remove some branches") Reported-by: Kent Overstreet # (on IRC) Signed-off-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) --- Changes since v2: https://lore.kernel.org/linux-trace-kernel/20231212065922.05f28041@gandalf.local.home - Just test 'w' first, and then do the rest of the checks. kernel/trace/ring_buffer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 8d2a4f00eca9..b8986f82eccf 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -3579,7 +3579,10 @@ __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer, * absolute timestamp. * Don't bother if this is the start of a new page (w == 0). */ - if (unlikely(!a_ok || !b_ok || (info->before != info->after && w))) { + if (!w) { + /* Use the sub-buffer timestamp */ + info->delta = 0; + } else if (unlikely(!a_ok || !b_ok || info->before != info->after)) { info->add_timestamp |= RB_ADD_STAMP_FORCE | RB_ADD_STAMP_EXTEND; info->length += RB_LEN_TIME_EXTEND; } else { @@ -3737,6 +3740,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; }