From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BB223F4123 for ; Tue, 7 Jul 2026 13:46:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783431981; cv=none; b=dDBgH81EAwm7I12YAWZHyDhXQ9Itojr6cCLsy7tSJ2ir4q/bg5e1iGAXYxcge97Sd3Iwq2OW3oA/jTUH6r8mqdIsZMKl6yZl59pPDYjRuITN5bsDb35SmmuiN7BK0SVxG2SJH46K9vv35vBHdxMxjO/95Pl0tLvOEstCmMVBFXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783431981; c=relaxed/simple; bh=U/j053Z4IyUjCT3aK+06zB0iO8m3pPHB+nQP1NU/0zk=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=GpL5qldez0CKNcYMQy/47+hLYWkyXBCNMTw00xhj5vlMTWA8Hy2gf4ZmUvxo0RlHNpNX6ifYoxkh+8EPj5O+6fKXlXEWrboUtaRgiDde+DOsVmjxjpvfYwxaBr1jIJUmnfJz4CToQUOYqTaYxrk/R4ryN3wZr/NhNgnac/7NhuI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gEf/9xUV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gEf/9xUV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AA781F00A3A; Tue, 7 Jul 2026 13:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783431980; bh=MnJNkpjk9rWK+KWOujTTgIGfE1WLfIwRlbR6LElltGI=; h=Date:From:To:Cc:Subject:References; b=gEf/9xUV1pdstu476Qn3Z+F8q+j4atJgUBuvDin6Z0036iDc/oekdgd3Gbe9gRqok mQCd4/qwlC19m/qMVqsZ2R+vhb/QyGevzt0jQ/oGoA6CcEgD/PtDGeZ4F894Z7LITO pDl6CrX5uJdNT8olNQ7P4LOuzKfSJuDpy+v3Trw0L97p6VW4HlUj3u3MeGZgpWDG3p yOP+XY7Eo5bBDIUaQSJZ0X3r617EKwnAOMqvH9XM8tDdMfjsmC9aEkoW7qfGuAbcE+ hd+4U5gV4SW2E6rOBAjkW21CbnZ75H/E9d30rIcvzryFOApc9CYbJjyKkHDPWNydCt FcXBriSkTw8Kw== Received: from rostedt by gandalf with local (Exim 4.99.4) (envelope-from ) id 1wh67z-00000000h1c-2EJF; Tue, 07 Jul 2026 09:46:23 -0400 Message-ID: <20260707134623.362855856@kernel.org> User-Agent: quilt/0.69 Date: Tue, 07 Jul 2026 09:46:06 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , Hui Wang Subject: [for-linus][PATCH 02/13] ring-buffer: Fix event length with forced 8-byte alignment References: <20260707134604.275787924@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Hui Wang When RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length() reserves the space of event->array[0] for placing the data length and rb_update_event() stores the data length in event->array[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally. But ring_buffer_event_length() only subtracts the sizeof(event->array[0]) for events larger than RB_MAX_SMALL_DATA + sizeof(event->array[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4 bytes larger than expected. To fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract the size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is true. This issue is observed in a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest trace_marker_raw.tc, we get the weird log: for cases where the id is 1..100, the number of data field is 8*N, but once id exceeds 100, the number of data field becomes 8*N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1) ... # a buf: 58 ... (number of data field is 8*2) ... # 64 buf: 58 ... (number of data field is 8*13) # 65 buf: 58 ... (number of data field is 8*13+4) After applying this change, the number of data field keeps being 8*N+4 consistently. Link: https://patch.msgid.link/20260607072431.125633-2-hui.wang@canonical.com Fixes: 2271048d1b3b ("ring-buffer: Do 8 byte alignment for 64 bit that can not handle 4 byte align") Signed-off-by: Hui Wang Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 56a328e94395..d9af2bbaf9c0 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -270,7 +270,8 @@ unsigned ring_buffer_event_length(struct ring_buffer_event *event) if (event->type_len > RINGBUF_TYPE_DATA_TYPE_LEN_MAX) return length; length -= RB_EVNT_HDR_SIZE; - if (length > RB_MAX_SMALL_DATA + sizeof(event->array[0])) + if (length > RB_MAX_SMALL_DATA + sizeof(event->array[0]) || + RB_FORCE_8BYTE_ALIGNMENT) length -= sizeof(event->array[0]); return length; } -- 2.53.0