Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1450308pxb; Wed, 10 Feb 2021 08:35:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+KF83cdREh0v2IblsgDJ6lRP7XNWnm3Yo5EddgxMP1KEFbvHNuHWBnWWt77VrRxafysoN X-Received: by 2002:a17:906:5043:: with SMTP id e3mr3802214ejk.260.1612974938510; Wed, 10 Feb 2021 08:35:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612974938; cv=none; d=google.com; s=arc-20160816; b=yAW+Fnd2lwOJ7BW1K1Idb5rH3H9Gn2G8hcgHHRCM436G+CwoRtkUxpK/Hhd64sfR7u QFz06CcEGZXdPFqscJVUmcsHD9LW1lsiLx/KSSxHS6Ob6Hn8VV5D1aaCpWCMofK6zW+s f5t6XiPOH+UHtx6cLuKI4Fa6HAGRjwk620vrSagCYuYAxLrEzRjzLbDneTAITOh5NX6W 3zF87dgy/kE1U0g2IX4W7co77PRHH5ZVU3RKcR2mkFtPvx4HmLaheeh28/XLg5AJqLeu L4YwZZt2gz+8azyD89nLLK9pILiXEJ6A3V6QhFHpxQvnO9PfgOpLPHUT6WY+3VDpizy1 Z7fA== 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 :references:in-reply-to:message-id:subject:cc:to:from:date; bh=ml2/zK3TD6A6LhmdUGM04VJkcP2xSWWm8vgKurizOik=; b=lFEsTI7ZYv1e29ENFhPVZ8fjdvVI2C3nUvlCC+pXvaSH7J0rzv+9MGeBiU+Bc9fQP4 t1dkbvqCgDCiFLcsZefKEE9vMvGez0fqVtp4BaewalJLu6iVpisUyCnu6UaptCOPBuHn fZzkiGySdgvVyHGbFZpWHhTTpBgzqb3Jtgl/QVYOB9bh0ZbeAqMXwxbUN7skSKkwlZ16 pzC9f5Hxbp4M3qUpfu44zP8HTPGbSftvgUCPaa07i+o3beQU7KC7cgMUgs7uXoMomYWa K4BAqq9fgeqkWezRCMW/KeZuAQIdGpnPS/3FD976LNCnamoIHGs7MSgcFXIBga0ZB63p cwqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s15si1700220edj.492.2021.02.10.08.35.14; Wed, 10 Feb 2021 08:35:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232590AbhBJQbe (ORCPT + 99 others); Wed, 10 Feb 2021 11:31:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:58576 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232557AbhBJQbJ (ORCPT ); Wed, 10 Feb 2021 11:31:09 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8DBC464E76; Wed, 10 Feb 2021 16:30:28 +0000 (UTC) Date: Wed, 10 Feb 2021 11:30:26 -0500 From: Steven Rostedt To: Wen Gong Cc: Brian Norris , ath10k , linux-wireless Subject: Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size Message-ID: <20210210113026.5f5ebe8a@gandalf.local.home> In-Reply-To: <9b479a88331dbf969f07708eabe53d14@codeaurora.org> References: <1612839593-2308-1-git-send-email-wgong@codeaurora.org> <20210209145531.5977b16d@gandalf.local.home> <20210209163431.11133472@gandalf.local.home> <9b479a88331dbf969f07708eabe53d14@codeaurora.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Wed, 10 Feb 2021 10:01:57 +0800 Wen Gong wrote: > Not tested with latest kernel. > The reason is below which I said in > https://lore.kernel.org/lkml/b504b3d7e989cae108669a0cd3072454@codeaurora.org/ > > the per cpu buffer seems it is initilized in > trace_buffered_event_enable, > it is only 1 page size as below: > void trace_buffered_event_enable(void) > { > ... > for_each_tracing_cpu(cpu) { > page = alloc_pages_node(cpu_to_node(cpu), > GFP_KERNEL | __GFP_NORETRY, 0); > If the size of buffer to trace is more than 1 page, such as 46680, then > it trigger kernel crash/panic in my case while run trace-cmd. > After debugging, the trace_file->flags in > trace_event_buffer_lock_reserve is 0x40b while run trace-cmd, and it is > 0x403 while collecting ftrace log. Yeah, looking at this, I do see that this is a bug upstream. Can you test this patch? -- Steve diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b79bcacdd6f9..a0b352aa23fe 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2739,7 +2739,7 @@ trace_event_buffer_lock_reserve(struct trace_buffer **current_rb, (entry = this_cpu_read(trace_buffered_event))) { /* Try to use the per cpu buffer first */ val = this_cpu_inc_return(trace_buffered_event_cnt); - if (val == 1) { + if (len < PAGE_SIZE && val == 1) { trace_event_setup(entry, type, trace_ctx); entry->array[0] = len; return entry;