Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp980568pxb; Fri, 22 Apr 2022 15:51:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfsQ9aZVGot8RhL1oL1ydmNSyAT/rE4ExCm7LgxoRChvnRZ8e9Wy3bePmNyOqoOs3vNPh9 X-Received: by 2002:a63:6984:0:b0:398:8db9:7570 with SMTP id e126-20020a636984000000b003988db97570mr5667095pgc.373.1650667907672; Fri, 22 Apr 2022 15:51:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650667907; cv=none; d=google.com; s=arc-20160816; b=09+gP4xEV1+8q+O6tFxE2oTeI7KmRKAymbRWYr9Zj4qPHCP4GbY3AQoobh0S8XKPo+ /1SuBI7h0H/IDKuZPZSo8UEh/iWUpF+CuiW977LuuKK23O4Zzre9wppSREIYyP2O3JfV wlkN2nk6wFedsG7WLlhDtfGuL4WzzlzHnOIDtWoFAbCzC842Ik5jTN+HYIvSyCDfALf/ Jh+/yvGwOTESnLd0KQ5rpO+uZGQz8P+BIqu6yBtfEUKrPGhlPLnhGM61AP8yWEoDFaII IRhgervyEsZzjlHBpNzMQ94TL6cW7I+UjHgLr+w5DOxV51uHwRhjcTGvoWNKzSkNTnfs xIVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Wxv1VHcdMAWKawTEifnINmazC29umb2i5gHiDAZVeBk=; b=usCV7yMj5kXR3euAeY327Zk6bmtrWCHplrywBwfJiKcjUZpDJSqYZL5pKPRWn9mxud nM0IQSjr1bAN5u5T3hZ2f8FgoHt1PNL2d7+hsn4070bIiG/rZZZovMziTuHUzEHgS3k8 fc6KehyOD2XHQr7XnIumctqdkYJdJTWk0WPOV0GxwTp7UVhBjKUmpoX4NNVotL2gsxM5 FSddtK7ujCt3Pc0BiLfE1vXYiqGYXF7oEqhMqoh+IEujW5Z8DYF1Xh7h6PyrW7jtW3Sr g6tdxUfuTxXlO+vZVZ/y6NDarfBfSAar8VwRTy45fNQ6pLTpfS3UHe0T+SBQkJNk+NV+ 4isw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20210112.gappssmtp.com header.s=20210112 header.b=335nWJbB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id ei16-20020a17090ae55000b001cbc357005asi11188392pjb.174.2022.04.22.15.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 15:51:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@toxicpanda-com.20210112.gappssmtp.com header.s=20210112 header.b=335nWJbB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E72322F8F88; Fri, 22 Apr 2022 13:42:00 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1449416AbiDVP1H (ORCPT + 99 others); Fri, 22 Apr 2022 11:27:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1449404AbiDVP1E (ORCPT ); Fri, 22 Apr 2022 11:27:04 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 734D256215 for ; Fri, 22 Apr 2022 08:24:10 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id r17so5245194iln.9 for ; Fri, 22 Apr 2022 08:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wxv1VHcdMAWKawTEifnINmazC29umb2i5gHiDAZVeBk=; b=335nWJbBDhabHr89gG5tFiLbFOQLvASDcW1EglELgq0uhxBp97C2KaIqEwRKVbYsmx GpS+ja0gF1YRQsUZmFTz2Nl2pDXP+Xg6v+vWDRNYMU8cLM1cbEfDWjFhC1kiLwXMHCqc eUNTTMg/IucTx/f6rGjggjmKpM7YImY+ja+IfNi+FzeDGPOhrYxJqIu19gGYohfQaFGV 0SRajNzdFfpfR5CbaoKsMJp5T0wjU80hAdAdMAGsWbQc6pgeR7DyeISxjBih7RRxtKeA yyb7xs1AH/m8scE0u5RTvPAz4HOf8cex/5nDUlehQfn/pXUbFnP8ggIcugUC7gLXuD4C AWYw== 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=Wxv1VHcdMAWKawTEifnINmazC29umb2i5gHiDAZVeBk=; b=CjP2FfkUVWOxKlzWLRdydqMf5RNtJf/ICmK04z3iJEk0ivO7ELxcam7Wnimf8BrQ4r Ws8c5C/HuMTEcEiOcswgSf/NiEmxnwN1elZuEIcujl+INQ2MabFUFxkuwZqIqQP5t3ME OZAhPcBn32I8UfDQwWHzZwaBfUzkQnkOgK7EM6CmSfZzcp5eVxbQ3F2ptEXH0kJx7ZYC kyJgQ0KXJaLtjLD8F3RHR+KuiV1nW4xRUIXWG7oONgvHLrTor3DpHcs2ZHFQqO/DENWz KHZxNmEsv46b1bvxr43wjDh3vQy6e3jtzrGw+MyB81hl/TJMpbhhC1M/Sd+fJxnERdc1 GUTA== X-Gm-Message-State: AOAM532aTjgwhZ4VjDzxPBCpxzNuZZKQKFaRBGARH9gDLZYGJnYiJHve gGPdmpQDo/PdlRvk8tvOCAeADFLjqWbNiEdiw/Otpg== X-Received: by 2002:a92:d2ca:0:b0:2ca:ca3a:de89 with SMTP id w10-20020a92d2ca000000b002caca3ade89mr2225426ilg.127.1650641049737; Fri, 22 Apr 2022 08:24:09 -0700 (PDT) MIME-Version: 1.0 References: <20220422054224.19527-1-matthew.ruffell@canonical.com> In-Reply-To: <20220422054224.19527-1-matthew.ruffell@canonical.com> From: Josef Bacik Date: Fri, 22 Apr 2022 11:23:58 -0400 Message-ID: Subject: Re: [PROBLEM] nbd requests become stuck when devices watched by inotify emit udev uevent changes To: Matthew Ruffell Cc: Jens Axboe , linux-block , nbd , Linux Kernel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 22, 2022 at 1:42 AM Matthew Ruffell wrote: > > Dear maintainers of the nbd subsystem, > > A user has come across an issue which causes the nbd module to hang after a > disconnect where a write has been made to a qemu qcow image file, with qemu-nbd > being the server. > Ok there's two problems here, but I want to make sure I have the right fix for the hang first. Can you apply this patch https://paste.centos.org/view/b1a2d01a and make sure the hang goes away? Once that part is fixed I'll fix the IO errors, this is just us racing with systemd while we teardown the device and then we're triggering a partition read while the device is going down and it's complaining loudly. Before we would set_capacity to 0 whenever we disconnected, but that causes problems with file systems that may still have the device open. However now we only do this if the server does the CLEAR_SOCK ioctl, which clearly can race with systemd poking the device, so I need to make it set_capacity(0) when the last opener closes the device to prevent this style of race. Let me know if that patch fixes the hang, and then I'll work up something for the capacity problem. Thanks, Josef