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 2420BC4332F for ; Wed, 16 Feb 2022 18:09:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E6E16B0075; Wed, 16 Feb 2022 13:09:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BBDC6B0078; Wed, 16 Feb 2022 13:09:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 784846B007B; Wed, 16 Feb 2022 13:09:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 69B4A6B0075 for ; Wed, 16 Feb 2022 13:09:47 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0B29985312 for ; Wed, 16 Feb 2022 18:09:47 +0000 (UTC) X-FDA: 79149431214.08.B509E2A Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 98094C0003 for ; Wed, 16 Feb 2022 18:09:46 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id e17so4607645ljk.5 for ; Wed, 16 Feb 2022 10:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dsoF6XbVRJnqOxLapkisfvdDBSbyOEKGfv87xWkqHBo=; b=H8EZzc3vbZYf96mKzjlBDBIZSlEvwXS9/cmk8gIRTNI1MAwfaOAbt22JaPzIFJh6SU haljNM84uLArCZw16a7/Bsg1jw9a9dpDJPFefdN6wlu3bpRuDM6rCoTBfs58oYcxVKD3 nbRVV3036QZdC6Y3iMcylW2hsU3GnC78jLfj8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dsoF6XbVRJnqOxLapkisfvdDBSbyOEKGfv87xWkqHBo=; b=tnmmQAw4/DcXgoYWCHw6m6pUojZnL+zsdg3BvnC4OMgVgRpYpdTvE5F/bbXQ21BwKS yCEGd8adVG9F43BD9kLumzbjRShD8beBHvsulxybpfqrqHUtbj8GGc7DWxjZC1D2Sp3E RprdnV0LQdvLyN/yAfiT87Wf7apG9MQOaIzNt9A1CLMDfm+xDAnnUnGWka6swkRshRHs kblYevk7sF8OPaF7BYmopLzKV41mvHLz7pY4Vh2sqypbOS/6oXtuCfuq2mD7Y5N9JCTo KddiFRdt9izV66leu0VUYj9as7qyuBATZR+ZakFVp21hNohAMZlbKGscChHbGe+txFf1 zzFQ== X-Gm-Message-State: AOAM532sqlQzPKn+ntSYoaZkD7xWDscCLcuQDTk7/f28VNqtdb8wUe00 unh5IpDY8U94I5WUZ5rikCBGj8gWDKVOVe9gJAU= X-Google-Smtp-Source: ABdhPJyNdidN4u8YlUaDBuJRXlPvjc+ICFNQnQ3kGOvciByAdLhpkOTR3D+AbRxrrWpRN82koQOoLQ== X-Received: by 2002:a2e:9284:0:b0:244:c5e8:b5c with SMTP id d4-20020a2e9284000000b00244c5e80b5cmr3011388ljh.131.1645034984508; Wed, 16 Feb 2022 10:09:44 -0800 (PST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id a12sm3542108lfu.162.2022.02.16.10.09.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Feb 2022 10:09:43 -0800 (PST) Received: by mail-lj1-f169.google.com with SMTP id u16so4626338ljk.2 for ; Wed, 16 Feb 2022 10:09:42 -0800 (PST) X-Received: by 2002:ac2:5313:0:b0:443:99c1:7e89 with SMTP id c19-20020ac25313000000b0044399c17e89mr289887lfh.531.1645034970931; Wed, 16 Feb 2022 10:09:30 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <94b1cba2-0e78-bbc0-0321-8be70b2b3be2@opensource.wdc.com> From: Linus Torvalds Date: Wed, 16 Feb 2022 10:09:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Report in ata_scsi_port_error_handler() To: Damien Le Moal Cc: Byungchul Park , linux-ide@vger.kernel.org, Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Will Deacon , Thomas Gleixner , Steven Rostedt , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 98094C0003 X-Stat-Signature: artb443rw1iftikdz31u3e55guh188qa X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=H8EZzc3v; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1645034986-846849 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 Tue, Feb 15, 2022 at 10:37 PM Damien Le Moal wrote: > > On 2/16/22 13:16, Byungchul Park wrote: > > [ 2.051040] =================================================== > > [ 2.051406] DEPT: Circular dependency has been detected. > > [ 2.051730] 5.17.0-rc1-00014-gcf3441bb2012 #2 Tainted: G W > > [ 2.051991] --------------------------------------------------- > > [ 2.051991] summary > > [ 2.051991] --------------------------------------------------- > > [ 2.051991] *** DEADLOCK *** > > [ 2.051991] > > [ 2.051991] context A > > [ 2.051991] [S] (unknown)(&(&ap->eh_wait_q)->dmap:0) > > [ 2.051991] [W] __raw_spin_lock_irq(&host->lock:0) > > [ 2.051991] [E] event(&(&ap->eh_wait_q)->dmap:0) > > [ 2.051991] > > [ 2.051991] context B > > [ 2.051991] [S] __raw_spin_lock_irqsave(&host->lock:0) > > [ 2.051991] [W] wait(&(&ap->eh_wait_q)->dmap:0) > > [ 2.051991] [E] spin_unlock(&host->lock:0) > > Sleeping with a spinlock held would be triggering warnings already, so > these reports seem bogus to me. Yeah, Matthew pointed out the same thing for another use-case, where it looks like DEPT is looking at the state at the wrong point (not at the scheduling point, but at prepare_to_sleep()). This ata_port_wait() is the exact same pattern, ie we have spin_lock_irqsave(ap->lock, flags); while (ap->pflags & (ATA_PFLAG_EH_PENDING | ATA_PFLAG_EH_IN_PROGRESS)) { prepare_to_wait(&ap->eh_wait_q, &wait, TASK_UNINTERRUPTIBLE); spin_unlock_irqrestore(ap->lock, flags); schedule(); and DEPT has incorrectly taken it to mean that 'ap->lock' is held during the wait, when it is actually released before actually waiting. For the spin-locks, this is all very obvious (because they'd have been caught long ago by much simpler debug code), but the same prepare_to_wait -> wait pattern can most definitely happen with sleeping locks too, so they are all slightly suspect. And yes, the detailed reports are hard to read because the locations are given as "ata_port_wait_eh+0x52/0xc0". Running them through scripts/decode_stacktrace.sh to turn them into filename and line numbers - and also sort out inlining - would help a lot. 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.. Linus