From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 383A8C433E6 for ; Wed, 20 Jan 2021 19:45:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC4722343F for ; Wed, 20 Jan 2021 19:45:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392520AbhATTop (ORCPT ); Wed, 20 Jan 2021 14:44:45 -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(-)