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;
Date:   Sun, 20 Nov 2022 14:49:56 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Yang Jihong <yangjihong1@huawei.com>
Cc:     <mhiramat@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing: Fix infinite loop in tracing_read_pipe on
 overflowed print_trace_line
Message-ID: <20221120144956.30bb1725@rorschach.local.home>
In-Reply-To: <188a48b7-f426-6348-086e-22e56bb07206@huawei.com>
References: <20221114022946.66255-1-yangjihong1@huawei.com>
        <20221117164003.6e655615@gandalf.local.home>
        <188a48b7-f426-6348-086e-22e56bb07206@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 18 Nov 2022 18:21:12 +0800
Yang Jihong <yangjihong1@huawei.com> wrote:

> > That way we can see the broken trace event and not just silently drop it.
> >   
> Ok, will change in next version.(Because iter->seq.seq.len may be 
> smaller than strlen(dots), direct subtraction here may not be appropriate.)

We should only need to do this if the len is maxed out.

Hmm, len is only updated if it did actually copy it.

Perhaps we could just add:

	trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n");

And perhaps that will work?

Anyway, what is triggering this?

-- Steve