From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FE1FC433F5 for ; Wed, 16 Feb 2022 18:33:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A02F46B0075; Wed, 16 Feb 2022 13:33:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B3316B0078; Wed, 16 Feb 2022 13:33:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 854786B007B; Wed, 16 Feb 2022 13:33:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 788046B0075 for ; Wed, 16 Feb 2022 13:33:27 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 409CC181AC9C6 for ; Wed, 16 Feb 2022 18:33:27 +0000 (UTC) X-FDA: 79149490854.13.FE7411D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id B823C4000B for ; Wed, 16 Feb 2022 18:33:26 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BB466615F0; Wed, 16 Feb 2022 18:33:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE3B5C340E8; Wed, 16 Feb 2022 18:33:19 +0000 (UTC) Date: Wed, 16 Feb 2022 13:33:18 -0500 From: Steven Rostedt To: Linus Torvalds Cc: Damien Le Moal , Byungchul Park , linux-ide@vger.kernel.org, Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Will Deacon , Thomas Gleixner , Joel Fernandes , Sasha Levin , Daniel Vetter , Chris Wilson , duyuyang@gmail.com, johannes.berg@intel.com, Tejun Heo , "Theodore Ts'o" , Matthew Wilcox , Dave Chinner , Amir Goldstein , "J. Bruce Fields" , Greg Kroah-Hartman , kernel-team@lge.com, Linux-MM , Andrew Morton , Michal Hocko , Minchan Kim , Johannes Weiner , Vladimir Davydov , sj@kernel.org, Jerome Glisse , Dennis Zhou , Christoph Lameter , Pekka Enberg , David Rientjes , Vlastimil Babka , ngupta@vflare.org, linux-block , Jens Axboe , paolo.valente@linaro.org, Josef Bacik , linux-fsdevel , Al Viro , Jan Kara , Jeff Layton , Dan Williams , Christoph Hellwig , "Darrick J. Wong" , dri-devel , Dave Airlie , rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com Subject: Re: Report in ata_scsi_port_error_handler() Message-ID: <20220216133318.204f36ac@gandalf.local.home> In-Reply-To: References: <1644984747-26706-1-git-send-email-byungchul.park@lge.com> <1644984964-28300-1-git-send-email-byungchul.park@lge.com> <1644984964-28300-3-git-send-email-byungchul.park@lge.com> <94b1cba2-0e78-bbc0-0321-8be70b2b3be2@opensource.wdc.com> 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 X-Rspamd-Queue-Id: B823C4000B X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of "SRS0=QDLd=S7=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=QDLd=S7=goodmis.org=rostedt@kernel.org"; dmarc=none X-Stat-Signature: 1mu4hr9iss96bhk5197zbggn9f615izu X-Rspamd-Server: rspam03 X-HE-Tag: 1645036406-963657 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 16 Feb 2022 10:09:14 -0800 Linus Torvalds wrote: > Byungchul, could you fix those two issues? Some of your reports may > well be entirely valid, but the hard-to-read hex offsets and the > knowledge that at least some of them are confused about how > prepare_to_wait -> wait actually works makes the motivation to look at > the details much less.. Hi Byungchul, I'm not sure what your tool is using to attach to the kernel to analyze the events (perhaps tracepoints?). But you can have the prepare_to_wait event just flag the task is about to wait, and then attach to the schedule (sched_switch) event to denote that it actually waited. Of course have the finish_wait() clear the flag. -- Steve