Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp638009pxb; Wed, 20 Jan 2021 16:55:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwV5GCoDxHgGJNJlPh72srXca3XkDJjOCSwwhUDd5P+kM2LTjIzHVvqbQc3E7WgPmWfNiRM X-Received: by 2002:a17:906:1c17:: with SMTP id k23mr7431349ejg.255.1611190512522; Wed, 20 Jan 2021 16:55:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611190512; cv=none; d=google.com; s=arc-20160816; b=XrXqZ9K/Bd6zrafcDdpY4Ckti9A/Y/EjIp5IDcen75M9YF8oxQrLMVnC9YVsDHcomN 7QA7KpTTFIju62hu//Fkam7Z/76nTg3j8ad49CNqp/Z/BRI1ksJapFUSywX4H7DVjEDM CS5T6Fo9jbV7xAoRlThxh8+dpyajD4nIdltSnOdRnGT33jMu6czepCjL0DMrAbnSjkNi HaTvCYOt6qz9ci0LDVYfUp0cOQhNPqzJ73xTsbpdNznOqXnWQZ+TNgRzd9zFFeEeF3TR 9seUlQhXJTWg1yuFtpD+4eJNQIV9BXEpIQcGfpl/eXyVLD/4/HOwr2lhF5cLICz1uWwx n3TA== 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:message-id:date:cc:to:from:subject:ironport-sdr :ironport-sdr; bh=NDWGGfcDKI8rHC+AyUkjQLFY9inI1Eet74JWyMWZaWM=; b=eHBLX1f/IjNvkdUDT/vyVBoLlC5TNwRA9wuPFHVCpUxHRumsKCq4QBIUA7g52dqm3Y S0QAJ5ml96FFRNytLQO9meKyOLfQDiuRP5quuKR+5/Q9TumT5YApWhz0S7NxEqprtaEX mpj3YDue99ygGwcIezAoLyRYZlj/Qc/pedFdVh8fE2PFAnEuUWRgI0EnJyxiulV3PKiP WvDhQ33SKTOOuOUbhdHAuZvFmkPNH/TGpMxvdkkFEb+8kuAS2D7KVd6uSL7yFknxH6ai SsRZOwy6oCs02N6g2uQ3iK1L2FSDQhqztBh3DeGDM+gYoMj7fftjUIO9Xzj8xp12QMXT BOtg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pk24si1208648ejb.739.2021.01.20.16.54.48; Wed, 20 Jan 2021 16:55:12 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730782AbhATToi (ORCPT + 99 others); Wed, 20 Jan 2021 14:44:38 -0500 Received: from mga07.intel.com ([134.134.136.100]:59892 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392630AbhATTkF (ORCPT ); Wed, 20 Jan 2021 14:40:05 -0500 IronPort-SDR: bb9BFarngYYjDuE8Ku+FK+3qdJChux06CiNlEYtw+y2sJUkypI0oHXNBBHGfE9mrgtJpeEmHAK JAeI1YIf3qCw== X-IronPort-AV: E=McAfee;i="6000,8403,9870"; a="243236611" X-IronPort-AV: E=Sophos;i="5.79,361,1602572400"; d="scan'208";a="243236611" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2021 11:38:52 -0800 IronPort-SDR: pzhuB8GNi4NcFuaNPvuKg3ijSwwxzX6vhRsPNgcaN3iWjTooCAwL1Ft65HVPryvJipqrsV6g1C Z27Es84BmAxw== X-IronPort-AV: E=Sophos;i="5.79,361,1602572400"; d="scan'208";a="501708581" Received: from dwillia2-desk3.jf.intel.com (HELO dwillia2-desk3.amr.corp.intel.com) ([10.54.39.25]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2021 11:38:52 -0800 Subject: [PATCH 0/3] cdev: Generic shutdown handling From: Dan Williams To: gregkh@linuxfoundation.org Cc: Ira Weiny , Dave Jiang , Alexandre Belloni , Alexander Viro , Vishal Verma , Logan Gunthorpe , Hans Verkuil , logang@deltatee.com, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org Date: Wed, 20 Jan 2021 11:38:52 -0800 Message-ID: <161117153248.2853729.2452425259045172318.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: StGit/0.18-3-g996c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org After reviewing driver submissions with new cdev + ioctl usages one common stumbling block is coordinating the shutdown of the ioctl path, or other file operations, at driver ->remove() time. While cdev_del() guarantees that no new file descriptors will be established, operations on existing file descriptors can proceed indefinitely. Given the observation that the kernel spends the resources for a percpu_ref per request_queue shared with all block_devices on a gendisk, do the same for all the cdev instances that share the same cdev_add()-to-cdev_del() lifetime. With this in place cdev_del() not only guarantees 'no new opens', but it also guarantees 'no new operations invocations' and 'all threads running in an operation handler have exited that handler'. As a proof point of the way driver implementations open-code around this gap in the api the libnvdimm ioctl path is reworked with a result of: 4 files changed, 101 insertions(+), 153 deletions(-) --- Dan Williams (3): cdev: Finish the cdev api with queued mode support libnvdimm/ida: Switch to non-deprecated ida helpers libnvdimm/ioctl: Switch to cdev_register_queued() drivers/nvdimm/btt_devs.c | 6 + drivers/nvdimm/bus.c | 177 +++++++++------------------------------ drivers/nvdimm/core.c | 14 ++- drivers/nvdimm/dax_devs.c | 4 - drivers/nvdimm/dimm_devs.c | 53 +++++++++--- drivers/nvdimm/namespace_devs.c | 14 +-- drivers/nvdimm/nd-core.h | 14 ++- drivers/nvdimm/pfn_devs.c | 4 - fs/char_dev.c | 108 ++++++++++++++++++++++-- include/linux/cdev.h | 21 ++++- 10 files changed, 238 insertions(+), 177 deletions(-)