Received: by 2002:a89:2c3:0:b0:1ed:23cc:44d1 with SMTP id d3csp115430lqs; Mon, 4 Mar 2024 17:33:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXuA+sAue8H4EwlPtu3+x35MVam7WWzvtPvCsu+sETw/I7DpA0QXRRmZFjgvaoPZImzgJAPS1TMMj2fldQXWcuMaR7mQJBJbir5GmXZVg== X-Google-Smtp-Source: AGHT+IH4nNho46deD0cVY/XUAdg0U/E1/tBOtmJTAJffCTXdaOGngdSGCQl+VRgbmTJUgswNn0JB X-Received: by 2002:a05:6402:26d6:b0:567:dea:c3bf with SMTP id x22-20020a05640226d600b005670deac3bfmr5412838edd.41.1709602415501; Mon, 04 Mar 2024 17:33:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709602415; cv=pass; d=google.com; s=arc-20160816; b=slCJVsTNN/yHG/vIeY7MbeN7pECM+RKKINYxJnBUpp/jSCXaOf6CkGCou2ThHslCwR Z7RvkTSOdnmUaEENqBbbpxBOzw0XP6lNksz6iSOteL4f2ZC4wFwBshLYvphz5T+H1qTn vPSeJJS9l7/tVaWF/0elSb0nHb7DB3VIP8cmCE64oF6EuSwPUDF1YQc+UEyCEh3hrQ1L zI17YHYERMv60OmScqtfvOxKybh0UWBI9VFdWL+b/8J77wN+Qg/NqI7X6xFqqNzXY1A8 m1Enx0bTDtGrlZlf8sshmCtoaTUw/nScqaPsYpyRiehCUjsNUQRy9EOGleIL9sAgnifD nJeQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date; bh=qz0/6smH9nx0Yra2VzyCRo/Rq1hW+gam73vFItzfaIY=; fh=5GSL8iMgAyuzpToQ7VTfMGDhy7T5RKF49tB9TFqJckE=; b=WmpGpE4QFriwJQZlogUQ1pbazsybioDe3n3XakVXTdngoSXgUrDT+NjtQjb8sAbeAH 31xV/ZkzN8fe1J+pTuiDtZVbR4MigsY+zan8/J/VNX+PNDy8yE0yD39/auNDOJMWBANC kKjxWqdCN1VbLGGRGJsXw/ZdYDmRfpcsJmlMLvo6wwKKZ52SgVPvTcIa8bIMPfNL2t2d MpY/kA8Iv6unhn0+AtjbBsacJxDocBj+hYACoWZMTfWRQpAsTYO+dtw0Xd0lNQoTeCiZ M07suvOYvnaM3jgHlxWdEDdRZ1IqaBpBTyBbIEUyPKYHcLtj1mIga6xBye9xEhdUsBky Rvjg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-91497-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-91497-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id n18-20020a509352000000b00564432aa4f9si4424058eda.411.2024.03.04.17.33.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 17:33:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-91497-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-91497-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-91497-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 220861F22ECC for ; Tue, 5 Mar 2024 01:33:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8614117C6C; Tue, 5 Mar 2024 01:33:29 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0AAD018037; Tue, 5 Mar 2024 01:33:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709602409; cv=none; b=PmdkJ4xlTTTQdgPhecaUwZ1xerpZmu1I9Iyb395eX/AChofS8hiuAMk4U3xmvtFN5DtBxOYJjxCV5DViDn2Zn8k9TBr5dKYyE69tyKt0k5HtrQK1eFVboFSEZREwupzWRB9GaABNOE2DYgfZAobvq3aLvfZvykHvNvctGpkwAXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709602409; c=relaxed/simple; bh=biGDkyvzPAl9aI4dKCIf9uUJJPcyOor9x961zx4tvfo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XYDMgSNtUImQYB5KkzLTPMA0cgNNB8XntQNXsy2eiK3O3vh2gqzBKEly94qdRdhAMSTd2885dHVeEiT7qL70GZM2vAtnWgKyXHYJeWxPNYAiGehQVEh2w+ZGwIDjgU9VGZ0wyeHFbG2oeQbch4mGAJ4LBqwV/4AXxWTY+UOC804= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26F21C433C7; Tue, 5 Mar 2024 01:33:28 +0000 (UTC) Date: Mon, 4 Mar 2024 20:35:16 -0500 From: Steven Rostedt To: Mathieu Desnoyers Cc: LKML , Linux Trace Kernel , Masami Hiramatsu , Linus Torvalds , Sachin Sant Subject: Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE Message-ID: <20240304203516.45b7a551@gandalf.local.home> In-Reply-To: <469d31a7-f358-4547-bb17-0979b3515924@efficios.com> References: <20240304192710.4c99677c@gandalf.local.home> <469d31a7-f358-4547-bb17-0979b3515924@efficios.com> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 4 Mar 2024 20:15:57 -0500 Mathieu Desnoyers wrote: > On 2024-03-04 19:27, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > Since the size of trace_seq's buffer is the max an event can output, have > > the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That > > will keep writes that has meta data written from being dropped (but > > reported), because the total output of the print event is greater than > > what the trace_seq can hold. > > Defining the trace_mark limit in terms of "TRACE_SEQ_SIZE / 2" > seems backwards. It's basically using a define of the maximum > buffer size for the pretty-printing output and defining the maximum > input size of a system call to half of that. > > I'd rather see, in a header file shared between tracing mark > write implementation and output implementation: > > #define TRACING_MARK_MAX_SIZE 4096 > > and then a static validation that this input fits within your > pretty printing output in the output implementation file: > > BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) > TRACE_SEQ_SIZE); That's not the meta size I'm worried about. The sizeof(meta data) is the raw event binary data, which is not related to the size of the event output. # cd /sys/kernel/tracing # echo hello > trace_marker # cat trace [..] <...>-999 [001] ..... 2296.140373: tracing_mark_write: hello ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the meta data that is added to trace_seq -- Steve > > This way we clearly document that the tracing mark write > input limit is 4kB, rather than something derived from > the size of an output buffer. > > Thanks, > > Mathieu > > > > > Signed-off-by: Steven Rostedt (Google) > > --- > > kernel/trace/trace.c | 16 +++++++++++----- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > > index 8198bfc54b58..d68544aef65f 100644 > > --- a/kernel/trace/trace.c > > +++ b/kernel/trace/trace.c > > @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char __user *ubuf, > > if ((ssize_t)cnt < 0) > > return -EINVAL; > > > > + /* > > + * TRACE_SEQ_SIZE is the total size of trace_seq buffer used > > + * for output. As the print event outputs more than just > > + * the string written, keep it smaller than the trace_seq > > + * as it could drop the event if the extra data makes it bigger > > + * than what the trace_seq can hold. Half he TRACE_SEQ_SIZE > > + * is more than enough. > > + */ > > + if (cnt > TRACE_SEQ_SIZE / 2) > > + cnt = TRACE_SEQ_SIZE / 2; > > + > > meta_size = sizeof(*entry) + 2; /* add '\0' and possible '\n' */ > > again: > > size = cnt + meta_size; > > @@ -7328,11 +7339,6 @@ tracing_mark_write(struct file *filp, const char __user *ubuf, > > if (cnt < FAULTED_SIZE) > > size += FAULTED_SIZE - cnt; > > > > - if (size > TRACE_SEQ_BUFFER_SIZE) { > > - cnt -= size - TRACE_SEQ_BUFFER_SIZE; > > - goto again; > > - } > > - > > buffer = tr->array_buffer.buffer; > > event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size, > > tracing_gen_ctx()); >