Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6011000ybi; Wed, 29 May 2019 01:12:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrpZ0uJS81ryg0cUx+EvGFrRG9QzDe2WkkY0e1giId5aOfYE6PDGA+nRZuS/kem7TQbHqQ X-Received: by 2002:a17:902:9f8b:: with SMTP id g11mr132924979plq.199.1559117520180; Wed, 29 May 2019 01:12:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559117520; cv=none; d=google.com; s=arc-20160816; b=fRfEGjCYnMsRtXCf1U8eggclzNEz3VnA5wON/ZnnXqkfSbzgiNGXG9N0ocOZ6ApCCZ UxPJ2fqB8Bq976uuc33dJ9XqPAToom9rSHTZ4epaRGAuagtdg5ccbDEF5UYI9bcC2jcs E0hUKfrEpQY0WbE9GeLPdrH31MCEFwfM6O8QOajaDrcXlJBMvy5qiF3R4+NL69SF/42W ErRMG11pRpIkcHLaQhruHNeeowJW7CyMrY7BqlwzPFgbtsN+Y5Naj3JvJquWla5DNBjO GANURzd7Vy1OtDoAWaltd2YUR9n7pjNUunVHq7mZP5UyGMv9t9/pNB/vC2GEUEDbXnJu jcbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=q77oFp8VTyT+b9cpW/UHYGK4jwD/19bbboyLgT1MWDA=; b=Kp5snf44oBD22vm9svL5BRkrwRK4wTu2+HVMEQhLuNU5uki1fdOa6VAMkS005cnAZP uew+NXgdjm218sxh6NRamiP3irL+lALop1q7CqeIfj/nJpA4be9et5ifCQMg9SDNJ857 iaCAe3G8BdsAAyCai1Vqu63Go2pihVniGfeL9N1zPE0Dgyy1sVnD+tPaQYN4V++7T/Vu N5OybJxYCrU+lqJblPXFQJ3efFDvD5na1HOMBvPRlcStqA5lMbMkSKt+zo2oZoRoDGVF 5IavDj3hRhb8E1y1RnD7KkhuEt+pzHrtk0SF0YS64pGvP4MeEWyMtk1Q3/xEJ41B9B1P ifpQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 11si24868636pgn.297.2019.05.29.01.11.43; Wed, 29 May 2019 01:12:00 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726784AbfE2IJm (ORCPT + 99 others); Wed, 29 May 2019 04:09:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37236 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726687AbfE2IJm (ORCPT ); Wed, 29 May 2019 04:09:42 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AE34A3087958; Wed, 29 May 2019 08:09:41 +0000 (UTC) Received: from rhel3.localdomain (ovpn-12-18.pek2.redhat.com [10.72.12.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id A22C36148C; Wed, 29 May 2019 08:09:38 +0000 (UTC) From: xiubli@redhat.com To: josef@toxicpanda.com, axboe@kernel.dk, nbd@other.debian.org Cc: mchristi@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, atumball@redhat.com, Xiubo Li Subject: [RFC PATCH] nbd: set the default nbds_max to 0 Date: Wed, 29 May 2019 16:08:36 +0800 Message-Id: <20190529080836.13031-1-xiubli@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 29 May 2019 08:09:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xiubo Li There is one problem that when trying to check the nbd device NBD_CMD_STATUS and at the same time insert the nbd.ko module, we can randomly get some of the 16 /dev/nbd{0~15} are connected, but they are not. This is because that the udev service in user space will try to open /dev/nbd{0~15} devices to do some sanity check when they are added in "__init nbd_init()" and then close it asynchronousely. Signed-off-by: Xiubo Li --- Not sure whether this patch make sense here, coz this issue can be avoided by setting the "nbds_max=0" when inserting the nbd.ko modules. drivers/block/nbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 4c1de1c..98be6ca 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -137,7 +137,7 @@ struct nbd_cmd { #define NBD_DEF_BLKSIZE 1024 -static unsigned int nbds_max = 16; +static unsigned int nbds_max; static int max_part = 16; static struct workqueue_struct *recv_workqueue; static int part_shift; @@ -2310,6 +2310,6 @@ static void __exit nbd_cleanup(void) MODULE_LICENSE("GPL"); module_param(nbds_max, int, 0444); -MODULE_PARM_DESC(nbds_max, "number of network block devices to initialize (default: 16)"); +MODULE_PARM_DESC(nbds_max, "number of network block devices to initialize (default: 0)"); module_param(max_part, int, 0444); MODULE_PARM_DESC(max_part, "number of partitions per device (default: 16)"); -- 1.8.3.1