Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1133545pxb; Thu, 4 Mar 2021 04:19:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdd2RAbC9eNamTykpz+fSu9pcim2s4qlf7uGxYimtXy3PwiwrcXrcEAbtH9Xpmm4Hi0iwO X-Received: by 2002:a17:906:c051:: with SMTP id bm17mr3802918ejb.21.1614860347843; Thu, 04 Mar 2021 04:19:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614860347; cv=none; d=google.com; s=arc-20160816; b=ViGviLBucKlbhzvjKQfJL/qd4bj52EsfLfTeZKf4g9WfNnWfpWnw+mFRlGFXjAguho FvqnHSuIrBkoyKX6MM8vkzFpM5RX0X0M+zl05lUG6Ujoo8tW9nqeg423JuawFKkl4pAB bEhjSQFHxa+D9E7I2EsMx7nkqdFTfWvd/WULFWffXfh5x3d1yvUUvTvyMmgzuEe1SW86 +9tkdMOah2ekVOyxt+MdFoCkYSBDiXgWUUzW4SK0j3uO0SRM6vjGySTTuygnEFrRk9zF t+Udso4zKUVAc7msvtyD0nYEpBbakHEGck3zn9RsovmN2sdVFULgEdqyZHcGqaNgHR3v Nyrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=egCST0Rney7JPu2RYQem6LVUwo8s+4euh2SRmmo9eVM=; b=mfKoLbY8CcFyDf+HdlHlagNUbQTo1IielRU2auiGVEf9AEWNycjQMENh69oFiaLsqc hGT3xc+QclfFZjM7LUSWjsDl7sIkCFUQunYpXYZVe+WdVs2tNz/giC4jvcsaFZbW6C7g yaGpQuIou0/vq+cp85YI22xT+JRCwCF18UAiHWbPxZO8h3L6GNw4BfRPwJQIn1u5m0my l+LrT6MFGzAVvEgpQCSWD7hKZJC/ZFdElHKrknePnBWV55jJxN+Q1DkjzEVQQ9zZnI3j tlJr7WejDr/5sgQrzGLKMOY4Lb+1N7Y8o/NhZK3vXb2x9QBws3gLkyhtLmtQtF5co71B DkpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=cAXBQI+q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i8si17876999ejj.286.2021.03.04.04.18.45; Thu, 04 Mar 2021 04:19:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=cAXBQI+q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386792AbhCCSqh (ORCPT + 99 others); Wed, 3 Mar 2021 13:46:37 -0500 Received: from mx2.suse.de ([195.135.220.15]:39946 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359034AbhCCRbY (ORCPT ); Wed, 3 Mar 2021 12:31:24 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1614792635; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=egCST0Rney7JPu2RYQem6LVUwo8s+4euh2SRmmo9eVM=; b=cAXBQI+qNeBUJXGyjZkZPTVerspuX5S3hVS/whxo5bEk4HcJAyN3wgJbnpW2dLUDu9LQgj ISRy6RYv/DgPHpi0wjC0ar/wLUuaJQLi9uCi54CyrTigVAnG+lCsZjiBOUSt671jzp+tAc HpERgrxQ6YoHMoNSW9xQWtPPOchiFFM= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6A546AC24; Wed, 3 Mar 2021 17:30:35 +0000 (UTC) Message-ID: <66a9b7ff4958ab990f58a3dad8152d00c59775ce.camel@suse.com> Subject: Re: [PATCH] block: Suppress uevent for hidden device when removed From: Martin Wilck To: Daniel Wagner , linux-block@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Jens Axboe , Christoph Hellwig Date: Wed, 03 Mar 2021 18:30:34 +0100 In-Reply-To: <20210303171201.8432-1-dwagner@suse.de> References: <20210303171201.8432-1-dwagner@suse.de> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.38.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2021-03-03 at 18:12 +0100, Daniel Wagner wrote: > register_disk() suppress uevents for devices with the GENHD_FL_HIDDEN > but enables uevents at the end again in order to announce disk after > possible partitions are created. > > When the device is removed the uevents are still on and user land > sees > 'remove' messages for devices which were never 'add'ed to the system. > > ? KERNEL[95481.571887] remove?? /devices/virtual/nvme- > fabrics/ctl/nvme5/nvme0c5n1 (block) > > Let's suppress the uevents for GENHD_FL_HIDDEN again before calling > device_del() which will write trigger uevents. > > Signed-off-by: Daniel Wagner > --- > ?block/genhd.c | 3 +++ > ?1 file changed, 3 insertions(+) > > diff --git a/block/genhd.c b/block/genhd.c > index c55e8f0fced1..ab9ed355bdef 100644 > --- a/block/genhd.c > +++ b/block/genhd.c > @@ -731,6 +731,9 @@ void del_gendisk(struct gendisk *disk) > ????????if (!sysfs_deprecated) > ????????????????sysfs_remove_link(block_depr, > dev_name(disk_to_dev(disk))); > ????????pm_runtime_set_memalloc_noio(disk_to_dev(disk), false); > + > +???????if (disk->flags & GENHD_FL_HIDDEN) > +???????????????dev_set_uevent_suppress(disk_to_dev(disk), 1); > ????????device_del(disk_to_dev(disk)); > ?} > ?EXPORT_SYMBOL(del_gendisk); I wonder if it wouldn't be wiser to remove this code if (disk->flags & GENHD_FL_HIDDEN) { dev_set_uevent_suppress(ddev, 0); return; } from register_disk(). The way you did it now, we would receive neither "add" nor "remove" events in user space, but there might be change events in between ? This said, I'd like to raise the question whether it was the right decision to suppress these uevents in the first place. 8ddcd653257c ("block: introduce GENHD_FL_HIDDEN") simply stated that they aren't registered as usable block devices. Maybe the kernel should leave the decision whether or not they are interesting to user space itself? For example, I've written an extension for multipath-tools some time ago which displays the topology of NVMe native multipath devices, and uses sysfs data from the hidden NVMe private namespaces for that purpose. Not receiving uevents for them makes it practically impossible to track the status of these devices. Regards, Martin