From patchwork Fri Mar 17 18:48:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Logan Gunthorpe X-Patchwork-Id: 740444 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail-qk0-x238.google.com (mail-qk0-x238.google.com [IPv6:2607:f8b0:400d:c09::238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vlDtm60jyz9ryr for ; Sat, 18 Mar 2017 05:50:40 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=googlegroups.com header.i=@googlegroups.com header.b="DJYnJDiV"; dkim-atps=neutral Received: by mail-qk0-x238.google.com with SMTP id 23sf49911814qke.1 for ; Fri, 17 Mar 2017 11:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:mime-version:from:to:cc:date:message-id:in-reply-to :references:subject:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FTJrCX01sl1IZGqs7tVrea8iH5Vwej4AsuJ9c3uF0rY=; b=DJYnJDiVMGusP1aQbS8NJi1RKxv9fooa6Gf7c7jigeOL85jGS3BDyduSAZI0agksQB JhmMOA7qcMp4E2BdcmJkY0KZtH6AsXzWtLl7f8t2L46gvir7XjyJbubhsvWrEapPIuFO 9OwrAf7yw5QWeRkPFEbb4hu3c1IyzMow61vSVxJcwwOOQaMrHwbzWXlQm42oYo/JES9m EfeRucLA5UGW24tv8X1qDYWLwyIXjKLDn3+i/HH3C9MGQ03B/FIQ32cR0DBvZLWidj4+ W9hdG9+ouW9RvLmkyoXTWYOLDzJKzz1B7Km1ZWx8HzZZwMiwKmUyoB2bKoJlix1nBkJD p2/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:mime-version:from:to:cc:date:message-id :in-reply-to:references:subject:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FTJrCX01sl1IZGqs7tVrea8iH5Vwej4AsuJ9c3uF0rY=; b=lSE7yTNLr7xFT314k6iYoPE7BFw69lRJ3n3fG4I+G/HM8fUnTnOALf5MlYx8gQkejZ LLPqSGgf6+5+w0mlm42aWSsJSLA6znua8EMoZZf9bEh+ecMdlJzQvNeKI1y2ibACTCWt oTsGgDWsc9f1VVaQE9uWUuRYu7o8PJqm4KhcXUDjUjdTImFfaBSZuuLH1t3ZYsulO16d 1BM+0jIzD0t3i2XdBd2RjDNbYU4kbDY4D+bYwO1GqUfC2SVxk53Pv3oi8RteqDwInFJG 82Jeb9lDLcFysIyWK+xhVFjQE21nRgAS+UiRcs9z8Y9GV1GD7E1f2DRAtS9wXInupHsD vgzA== Sender: rtc-linux@googlegroups.com X-Gm-Message-State: AFeK/H2eVZRUa+V6ppUjrUNSEjcJHTFpZXd9/sE3ntwQIQylijFXE12nuEmKG0qnbdkWdw== X-Received: by 10.36.50.129 with SMTP id j123mr247557ita.7.1489776638967; Fri, 17 Mar 2017 11:50:38 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: rtc-linux@googlegroups.com Received: by 10.107.156.16 with SMTP id f16ls2461600ioe.31.gmail; Fri, 17 Mar 2017 11:50:38 -0700 (PDT) X-Received: by 10.99.53.12 with SMTP id c12mr8079626pga.11.1489776638536; Fri, 17 Mar 2017 11:50:38 -0700 (PDT) Received: from ale.deltatee.com (ale.deltatee.com. [207.54.116.67]) by gmr-mx.google.com with ESMTPS id c123si1528039pfa.4.2017.03.17.11.50.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 11:50:38 -0700 (PDT) Received-SPF: pass (google.com: domain of gunthorp@deltatee.com designates 207.54.116.67 as permitted sender) client-ip=207.54.116.67; Received: from cgy1-donard.priv.deltatee.com ([172.16.1.31]) by ale.deltatee.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cowvs-0002Z8-Sg; Fri, 17 Mar 2017 12:49:10 -0600 Received: from gunthorp by cgy1-donard.priv.deltatee.com with local (Exim 4.84_2) (envelope-from ) id 1cowvo-0000pm-Uv; Fri, 17 Mar 2017 12:48:57 -0600 From: Logan Gunthorpe To: Greg Kroah-Hartman , Dan Williams , Hans Verkuil , Alexander Viro , Alexandre Belloni , Jason Gunthorpe , Johannes Thumshirn , Dmitry Torokhov , Linus Walleij , Jarkko Sakkinen , "James E.J. Bottomley" , "Martin K. Petersen" , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Cyrille Pitchen Cc: linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org, rtc-linux@googlegroups.com, linux-mtd@lists.infradead.org, linux-media@vger.kernel.org, linux-iio@vger.kernel.org, linux-rdma@vger.kernel.org, linux-gpio@vger.kernel.org, linux-input@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Logan Gunthorpe Date: Fri, 17 Mar 2017 12:48:08 -0600 Message-Id: <1489776503-3151-2-git-send-email-logang@deltatee.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1489776503-3151-1-git-send-email-logang@deltatee.com> References: <1489776503-3151-1-git-send-email-logang@deltatee.com> X-SA-Exim-Connect-IP: 172.16.1.31 X-SA-Exim-Rcpt-To: gregkh@linuxfoundation.org, dan.j.williams@intel.com, hans.verkuil@cisco.com, viro@zeniv.linux.org.uk, jgunthorpe@obsidianresearch.com, jthumshirn@suse.de, linus.walleij@linaro.org, jarkko.sakkinen@linux.intel.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, dwmw2@infradead.org, alexandre.belloni@free-electrons.com, boris.brezillon@free-electrons.com, dmitry.torokhov@gmail.com, computersforpeace@gmail.com, marek.vasut@gmail.com, cyrille.pitchen@atmel.com, rtc-linux@googlegroups.com, linux-mtd@lists.infradead.org, linux-nvdimm@lists.01.org, linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org, linux-media@vger.kernel.org, linux-iio@vger.kernel.org, linux-rdma@vger.kernel.org, linux-gpio@vger.kernel.org, linux-input@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, logang@deltatee.com X-SA-Exim-Mail-From: gunthorp@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-7.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE, LR_URI_NUMERIC_ENDING, MYRULES_FREE, MYRULES_NO_TEXT, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 Subject: [rtc-linux] [PATCH v5 01/16] chardev: add helper function to register char devs with a struct device X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) X-Original-Sender: logang@deltatee.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of gunthorp@deltatee.com designates 207.54.116.67 as permitted sender) smtp.mailfrom=gunthorp@deltatee.com Reply-To: rtc-linux@googlegroups.com Precedence: list Mailing-list: list rtc-linux@googlegroups.com; contact rtc-linux+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: rtc-linux@googlegroups.com X-Google-Group-Id: 712029733259 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Credit for this patch goes is shared with Dan Williams [1]. I've taken things one step further to make the helper function more useful and clean up calling code. There's a common pattern in the kernel whereby a struct cdev is placed in a structure along side a struct device which manages the life-cycle of both. In the naive approach, the reference counting is broken and the struct device can free everything before the chardev code is entirely released. Many developers have solved this problem by linking the internal kobjs in this fashion: cdev.kobj.parent = &parent_dev.kobj; The cdev code explicitly gets and puts a reference to it's kobj parent. So this seems like it was intended to be used this way. Dmitrty Torokhov first put this in place in 2012 with this commit: 2f0157f char_dev: pin parent kobject and the first instance of the fix was then done in the input subsystem in the following commit: 4a215aa Input: fix use-after-free introduced with dynamic minor changes Subsequently over the years, however, this issue seems to have tripped up multiple developers independently. For example, see these commits: 0d5b7da iio: Prevent race between IIO chardev opening and IIO device (by Lars-Peter Clausen in 2013) ba0ef85 tpm: Fix initialization of the cdev (by Jason Gunthorpe in 2015) 5b28dde [media] media: fix use-after-free in cdev_put() when app exits after driver unbind (by Shauh Khan in 2016) This technique is similarly done in at least 15 places within the kernel and probably should have been done so in another, at least, 5 places. The kobj line also looks very suspect in that one would not expect drivers to have to mess with kobject internals in this way. Even highly experienced kernel developers can be surprised by this code, as seen in [2]. To help alleviate this situation, and hopefully prevent future wasted effort on this problem, this patch introduces a helper function to register a char device along with its parent struct device. This creates a more regular API for tying a char device to its parent without the developer having to set members in the underlying kobject. This patch introduce cdev_device_add and cdev_device_del which replaces a common pattern including setting the kobj parent, calling cdev_add and then calling device_add. It also introduces cdev_set_parent for the few cases that set the kobject parent without using device_add. [1] https://lkml.org/lkml/2017/2/13/700 [2] https://lkml.org/lkml/2017/2/10/370 Signed-off-by: Logan Gunthorpe Signed-off-by: Dan Williams Reviewed-by: Hans Verkuil Reviewed-by: Alexandre Belloni --- fs/char_dev.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/cdev.h | 5 +++ 2 files changed, 91 insertions(+) diff --git a/fs/char_dev.c b/fs/char_dev.c index 44a240c..fb8507f 100644 --- a/fs/char_dev.c +++ b/fs/char_dev.c @@ -471,6 +471,85 @@ int cdev_add(struct cdev *p, dev_t dev, unsigned count) return 0; } +/** + * cdev_set_parent() - set the parent kobject for a char device + * @p: the cdev structure + * @kobj: the kobject to take a reference to + * + * cdev_set_parent() sets a parent kobject which will be referenced + * appropriately so the parent is not freed before the cdev. This + * should be called before cdev_add. + */ +void cdev_set_parent(struct cdev *p, struct kobject *kobj) +{ + WARN_ON(!kobj->state_initialized); + p->kobj.parent = kobj; +} + +/** + * cdev_device_add() - add a char device and it's corresponding + * struct device, linkink + * @dev: the device structure + * @cdev: the cdev structure + * + * cdev_device_add() adds the char device represented by @cdev to the system, + * just as cdev_add does. It then adds @dev to the system using device_add + * The dev_t for the char device will be taken from the struct device which + * needs to be initialized first. This helper function correctly takes a + * reference to the parent device so the parent will not get released until + * all references to the cdev are released. + * + * This helper uses dev->devt for the device number. If it is not set + * it will not add the cdev and it will be equivalent to device_add. + * + * This function should be used whenever the struct cdev and the + * struct device are members of the same structure whose lifetime is + * managed by the struct device. + * + * NOTE: Callers must assume that userspace was able to open the cdev and + * can call cdev fops callbacks at any time, even if this function fails. + */ +int cdev_device_add(struct cdev *cdev, struct device *dev) +{ + int rc = 0; + + if (dev->devt) { + cdev_set_parent(cdev, &dev->kobj); + + rc = cdev_add(cdev, dev->devt, 1); + if (rc) + return rc; + } + + rc = device_add(dev); + if (rc) + cdev_del(cdev); + + return rc; +} + +/** + * cdev_device_del() - inverse of cdev_device_add + * @dev: the device structure + * @cdev: the cdev structure + * + * cdev_device_del() is a helper function to call cdev_del and device_del. + * It should be used whenever cdev_device_add is used. + * + * If dev->devt is not set it will not remove the cdev and will be equivalent + * to device_del. + * + * NOTE: This guarantees that associated sysfs callbacks are not running + * or runnable, however any cdevs already open will remain and their fops + * will still be callable even after this function returns. + */ +void cdev_device_del(struct cdev *cdev, struct device *dev) +{ + device_del(dev); + if (dev->devt) + cdev_del(cdev); +} + static void cdev_unmap(dev_t dev, unsigned count) { kobj_unmap(cdev_map, dev, count); @@ -482,6 +561,10 @@ static void cdev_unmap(dev_t dev, unsigned count) * * cdev_del() removes @p from the system, possibly freeing the structure * itself. + * + * NOTE: This guarantees that cdev device will no longer be able to be + * opened, however any cdevs already open will remain and their fops will + * still be callable even after cdev_del returns. */ void cdev_del(struct cdev *p) { @@ -570,5 +653,8 @@ EXPORT_SYMBOL(cdev_init); EXPORT_SYMBOL(cdev_alloc); EXPORT_SYMBOL(cdev_del); EXPORT_SYMBOL(cdev_add); +EXPORT_SYMBOL(cdev_set_parent); +EXPORT_SYMBOL(cdev_device_add); +EXPORT_SYMBOL(cdev_device_del); EXPORT_SYMBOL(__register_chrdev); EXPORT_SYMBOL(__unregister_chrdev); diff --git a/include/linux/cdev.h b/include/linux/cdev.h index f876361..408bc09 100644 --- a/include/linux/cdev.h +++ b/include/linux/cdev.h @@ -4,6 +4,7 @@ #include #include #include +#include struct file_operations; struct inode; @@ -26,6 +27,10 @@ void cdev_put(struct cdev *p); int cdev_add(struct cdev *, dev_t, unsigned); +void cdev_set_parent(struct cdev *p, struct kobject *kobj); +int cdev_device_add(struct cdev *cdev, struct device *dev); +void cdev_device_del(struct cdev *cdev, struct device *dev); + void cdev_del(struct cdev *); void cd_forget(struct inode *);