Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2129635imm; Wed, 16 May 2018 08:18:41 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp8298qv1wuANU4FXLsUvKRcpyceBVj3OX4ZSL2nyd8yM1/c+BzON3hmCz+MS1KGK4klHOs X-Received: by 2002:a63:ba4c:: with SMTP id l12-v6mr1065095pgu.157.1526483921666; Wed, 16 May 2018 08:18:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526483921; cv=none; d=google.com; s=arc-20160816; b=NQfgRWsl1QfJUb7lMeyK76ORXIczLyGmCUP9JSYOrPDYOrzdSncRqzokJmEgsE7HvB AVcGCtdlfYO0D6JoeufalEexmkAZKLZW3yZvG8l1cV1dDtrFND5Qt75oPXgRe0yzAAj2 D4B6XAwwDdCTAa1YMxKFinTGL31BCjMK7wiDfMAS1LsOh0GXw9vMJxxYkTRBUq9GkODC Byd6MwrCo2z8/XG/gibAGjXNjmt9NBWLmqsWt79fK84SwjnaAxvc3BKeUiR+f98qvZm5 ABnDiVVPKS4d3dZLhmkXzrucJ8thbVB73y3lGXC9PKBeB3uA1s5DuTuuq1C2iQGfguWV 6AJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=GAZy7LOB/YwMxC6xpNirlgKyDYJvQx4B1BDld8MXHBw=; b=tIrVWsspADJVhBMDtisE/PQHNl2y8y7xPAxRUKRH7aOAKc3qD0NhKf1RaRbgIy2Qt5 lEw1vb0B9GXHFKCIsMGwCl5H+cI0yBUS8/K/v7WRBjUUTOb///nLX05OyGR9Ykb7AvWV RwaWCq3mQwP13FYtfhlr1AhgNtB/gRXk0RFKCP/iUqX4FS18VPg+BNbyn8btsScZ5B2h 1Cdd+Lphr2d88dEKuboOSbW9RWWC6cWrUjbNrdYlViTamrfM4K8oN6wgiGtnNMUs+uIf XdkD96cUvZucrhroAFjNBAYIWrFtYX71ZONLpv9Qg2IONs1i+2mxRGeVbV7Bg8f46F7A BXUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ScPTIR6B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12-v6si2663475plo.406.2018.05.16.08.18.27; Wed, 16 May 2018 08:18:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ScPTIR6B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbeEPPRE (ORCPT + 99 others); Wed, 16 May 2018 11:17:04 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:41629 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbeEPPRB (ORCPT ); Wed, 16 May 2018 11:17:01 -0400 Received: by mail-pl0-f66.google.com with SMTP id az12-v6so608149plb.8 for ; Wed, 16 May 2018 08:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GAZy7LOB/YwMxC6xpNirlgKyDYJvQx4B1BDld8MXHBw=; b=ScPTIR6BC/sPvMOOEyP9sjyftHerXmP7vQoRyXgQqyT2HH1AxtxAo4P+eqBMtue1Ro CyJkkEnfxlkdcU1cJ7F2WRRaavLDLIG+xjk3bayZd94LvdRlClPUaPhBG+B94E0y/Azk 69McipX/yU/szHIzJzAh+rta5+G2ZJQbzxwBdy9fCjoQnQ3joPUn5ruadF/xYS2JsyjQ +EyU8MxpmvsU0psq7S5EIz4Rr3LWMYbu0BKKQCMqN5btoQy5VMLJyMAlGZT66JodwCI0 H/c5gs7iVQTxInMT/4hUo0dlhJKzFD77rxaAIZp2rF5xCmy2IAwG/zGjOBftqsnfP6Mz o6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GAZy7LOB/YwMxC6xpNirlgKyDYJvQx4B1BDld8MXHBw=; b=jL4aUarmvyWkCDdVSLQO+Nk0nCKsd1bZx1LkHNTFyvMH1IxpqUtruIvHay1Lsc7IE7 M+ViOR2i+3GIP1ipbyMD2pUZ+UDAv8YWEHFKyyUh71yeb4MU3kKgOWUSGX9W3dC3MUyP hWH7Xv8XWzO8PKK6GXX8+kkDjqsqb9wjeRlmBbGBqVPXlYffIGdx6nMdEUcSQCUPE2+E nGDfBa8aKE1bPCB1wbXJ42n8+RvSFO22vWI/AqLamBwomnsKodfrrKt6kDv6uY8T9rvd kI7+0lwoQoeMVX5ZqTr82f5dMpOojpGvNO7cFCi0vvmjT+F8TuYqQUET41E1zrLv75Mr ezIw== X-Gm-Message-State: ALKqPwfRCkQe95DJ3pEN9ryE/wXbdRfWVMEmsPVqMKM3y7+Prlpeh3Qz Kurr0+9bo5RkbF5we4pG+KHUI2qMxNEbZLAkWA+8aw== X-Received: by 2002:a17:902:264:: with SMTP id 91-v6mr1311341plc.341.1526483821026; Wed, 16 May 2018 08:17:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:d01:0:0:0:0 with HTTP; Wed, 16 May 2018 08:16:40 -0700 (PDT) In-Reply-To: <43327033306c3dd2f7c3717d64ce22415b6f3451.camel@wdc.com> References: <0000000000009b212b056ae6dbad@google.com> <343bbbf6-64eb-879e-d19e-96aebb037d47@I-love.SAKURA.ne.jp> <43327033306c3dd2f7c3717d64ce22415b6f3451.camel@wdc.com> From: Dmitry Vyukov Date: Wed, 16 May 2018 17:16:40 +0200 Message-ID: Subject: Re: INFO: task hung in blk_queue_enter To: Bart Van Assche Cc: "syzbot+c4f9cebf9d651f6e54de@syzkaller.appspotmail.com" , "syzkaller-bugs@googlegroups.com" , "dan.j.williams@intel.com" , "linux-block@vger.kernel.org" , "penguin-kernel@I-love.SAKURA.ne.jp" , "axboe@kernel.dk" , "linux-kernel@vger.kernel.org" , "jthumshirn@suse.de" , "alan.christopher.jenkins@gmail.com" , "hch@lst.de" , "martin.petersen@oracle.com" , "ming.lei@redhat.com" , "martin@lichtvoll.de" , "oleksandr@natalenko.name" , "hare@suse.com" , "ross.zwisler@linux.intel.com" , "keith.busch@intel.com" , "linux-ext4@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 16, 2018 at 4:56 PM, Bart Van Assche wrote: > On Wed, 2018-05-16 at 22:05 +0900, Tetsuo Handa wrote: >> One ore more threads are waiting for q->mq_freeze_depth to become 0. But the >> thread who incremented q->mq_freeze_depth at blk_freeze_queue_start(q) from >> blk_freeze_queue() is waiting at blk_mq_freeze_queue_wait(). Therefore, >> atomic_read(&q->mq_freeze_depth) == 0 condition for wait_event() in >> blk_queue_enter() will never be satisfied. But what does that wait_event() >> want to do? Isn't "start freezing" a sort of blk_queue_dying(q) == true? >> Since percpu_ref_tryget_live(&q->q_usage_counter) failed and the queue is >> about to be frozen, shouldn't we treat atomic_read(&q->mq_freeze_depth) != 0 >> as if blk_queue_dying(q) == true? That is, something like below: >> >> diff --git a/block/blk-core.c b/block/blk-core.c >> index 85909b4..59e2496 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -951,10 +951,10 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) >> smp_rmb(); >> >> wait_event(q->mq_freeze_wq, >> - (atomic_read(&q->mq_freeze_depth) == 0 && >> - (preempt || !blk_queue_preempt_only(q))) || >> + atomic_read(&q->mq_freeze_depth) || >> + (preempt || !blk_queue_preempt_only(q)) || >> blk_queue_dying(q)); >> - if (blk_queue_dying(q)) >> + if (atomic_read(&q->mq_freeze_depth) || blk_queue_dying(q)) >> return -ENODEV; >> } >> } > > That change looks wrong to me. Hi Bart, Why does it look wrong to you? > Additionally, I think that you are looking in > the wrong direction. Since blk_mq_freeze_queue_wait() and blk_queue_enter() > work fine for all block drivers except the loop driver I think that you should > have a closer look at how the loop driver uses this block layer functionality. > > Thanks, > > Bart. > > >