From patchwork Tue Feb 21 05:00:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Logan Gunthorpe X-Patchwork-Id: 730294 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail-yw0-x237.google.com (mail-yw0-x237.google.com [IPv6:2607:f8b0:4002:c05::237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vS7fy1VzNz9s2P for ; Tue, 21 Feb 2017 16:03:06 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=googlegroups.com header.i=@googlegroups.com header.b="r+UBiQQM"; dkim-atps=neutral Received: by mail-yw0-x237.google.com with SMTP id p77sf8214106ywg.1 for ; Mon, 20 Feb 2017 21:03:06 -0800 (PST) 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=kn3dD83SXqcXFV4Pg5dQYj0vkzFQQ3iN0PtxP7Pn1K4=; b=r+UBiQQM4AMa/iPLK5iLmqMx6ZGBT4zGv0Su8aTmj5wr3J4rlYn2FtEEFWTSzv7Tmg MMC1qlG8qwQuWhWsfmu+mouKqUDY7LFKImCIiPzRozOc/Ku5e16adNXcopqfRePDHV53 0ltcDL/HH4wVF27QMAzX9ZX+ZFmkEGzQ5i+ctOZ/WpjvI1Fb7UOgBQ70493kR6R6PKD/ LvuKGGcairWbZsleO6JIORZLIVCYgsF5zNzlsAEp+V0JV2Ef8dgoqsCGE09nvznz+bDD rTg4slJQWYzILryjjFw4/vaEdfOEa7P2u2N+7xytel1FnoHiE/LUlCIgkSZp/2sJ5oBl lBgg== 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=kn3dD83SXqcXFV4Pg5dQYj0vkzFQQ3iN0PtxP7Pn1K4=; b=C5VUrb8M9GhAz9w7smF3KAs8XksHZUrJlAMoCsDpe8jV/f5dh5tVor8FxOTRFgAAbB lYrxgJB4p1oOoyrB9QaYc1NmmKGf1q/ar2boLBWdeYWVIP2093Noqy4uO1GpxNMdEWqy sPB8KQvK3kYkhSltg+lsCdCpgw6Hr6AxtXon1P0z9KR5jpqJIT8mgj4BVzQVDzN4S/dr 2Y8Qo/W9EmLJPKK+GQkVusDpFw4RO8u5igrvVtnV8pcCtV/CP/SEgdwn/6p2X9yh89NJ WM5eFiLJTfek+fpq304Ibsa3j5w4MPPoveIPYTU8th4yjkNpQBixbuL1hHBHw3vL1o6P HFfA== Sender: rtc-linux@googlegroups.com X-Gm-Message-State: AMke39miXZlACKWDYBNnV+STGUkdrcxTgXXCB+Ys2xpy9tmN4jlhT+7/Dz/nLg+VPZ8auQ== X-Received: by 10.157.56.117 with SMTP id r50mr1577704otd.12.1487653384343; Mon, 20 Feb 2017 21:03:04 -0800 (PST) MIME-Version: 1.0 X-BeenThere: rtc-linux@googlegroups.com Received: by 10.157.54.152 with SMTP id h24ls1512627otc.30.gmail; Mon, 20 Feb 2017 21:03:04 -0800 (PST) X-Received: by 10.157.4.196 with SMTP id 62mr7983634otm.46.1487653384140; Mon, 20 Feb 2017 21:03:04 -0800 (PST) Received: from ale.deltatee.com (ale.deltatee.com. [207.54.116.67]) by gmr-mx.google.com with ESMTPS id 23si2940905pfw.4.2017.02.20.21.03.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 21:03:04 -0800 (PST) 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] helo=cgy1-donard.pmc-sierra.internal) by ale.deltatee.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cg2Zi-0005uv-97; Mon, 20 Feb 2017 22:01:22 -0700 Received: from gunthorp by cgy1-donard.pmc-sierra.internal with local (Exim 4.84_2) (envelope-from ) id 1cg2ZV-00030M-4V; Mon, 20 Feb 2017 22:01:05 -0700 From: Logan Gunthorpe To: Greg Kroah-Hartman , Dan Williams , Alexander Viro , Johannes Thumshirn , Jan Kara , Arnd Bergmann , Sajjan Vikas C , Dmitry Torokhov , Linus Walleij , Alexandre Courbot , Peter Huewe , Marcel Selhorst , Jarkko Sakkinen , Jason Gunthorpe , Olof Johansson , Doug Ledford , Sean Hefty , Hal Rosenstock , Dmitry Vyukov , Haggai Eran , Parav Pandit , Leon Romanovsky , Jonathan Cameron , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Hans Verkuil , Mauro Carvalho Chehab , Artem Bityutskiy , Richard Weinberger , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Cyrille Pitchen , Matt Porter , Alexandre Bounine , Andrew Morton , Joe Perches , Lorenzo Stoakes , Vladimir Zapolskiy , Alessandro Zummo , Alexandre Belloni , Boaz Harrosh , Benny Halevy , "James E.J. Bottomley" , "Martin K. Petersen" , Stephen Bates , Bjorn Helgaas Cc: linux-pci@vger.kernel.org, osd-dev@open-osd.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, tpmdd-devel@lists.sourceforge.net, 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: Mon, 20 Feb 2017 22:00:40 -0700 Message-Id: <1487653253-11497-2-git-send-email-logang@deltatee.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1487653253-11497-1-git-send-email-logang@deltatee.com> References: <1487653253-11497-1-git-send-email-logang@deltatee.com> X-SA-Exim-Connect-IP: 172.16.1.31 X-SA-Exim-Rcpt-To: gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk, jthumshirn@suse.de, jack@suse.cz, arnd@arndb.de, vikas.cha.sajjan@hpe.com, linus.walleij@linaro.org, tpmdd@selhorst.net, jarkko.sakkinen@linux.intel.com, jgunthorpe@obsidianresearch.com, olof@lixom.net, dledford@redhat.com, dan.j.williams@intel.com, sean.hefty@intel.com, haggaie@mellanox.com, peterhuewe@gmx.de, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, hans.verkuil@cisco.com, leon@kernel.org, jic23@kernel.org, mchehab@kernel.org, richard@nod.at, dwmw2@infradead.org, cyrille.pitchen@atmel.com, mporter@kernel.crashing.org, alexandre.bounine@idt.com, akpm@linux-foundation.org, joe@perches.com, dmitry.torokhov@gmail.com, gnurou@gmail.com, hal.rosenstock@gmail.com, pandit.parav@gmail.com, dedekind1@gmail.com, computersforpeace@gmail.com, marek.vasut@gmail.com, lstoakes@gmail.com, vz@mleia.com, a.zummo@towertech.it, boris.brezillon@free-electrons.com, alexandre.belloni@free-electrons.com, ooo@electrozaur.com, bhalevy@primarydata.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, stephen.bates@microsemi.com, dvyukov@google.com, bhelgaas@google.com, osd-dev@open-osd.org, rtc-linux@googlegroups.com, linux-mtd@lists.infradead.org, tpmdd-devel@lists.sourceforge.net, 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 01/14] 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 entirely to Dan Williams [1]. I've just fleshed out the comments and created the patch, but the premise remains exactly the same. 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 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. In [1], Dan notes he took inspiration for the form of the API device_add_disk. [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 --- fs/char_dev.c | 24 ++++++++++++++++++++++++ include/linux/cdev.h | 1 + 2 files changed, 25 insertions(+) diff --git a/fs/char_dev.c b/fs/char_dev.c index 44a240c..1f9246c 100644 --- a/fs/char_dev.c +++ b/fs/char_dev.c @@ -471,6 +471,29 @@ int cdev_add(struct cdev *p, dev_t dev, unsigned count) return 0; } +/** + * device_add_cdev() - add a char device to the system with a parent + * struct device + * @parent: the device structure of the parent + * @cdev: the cdev structure for the device + * @count: the number of consecutive minor numbers corresponding to this + * + * device_add_cdev() adds the char device represented by @p to the system, + * just as cdev_add does. 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. + * (Thus, cdev_del should be called before device_unregister.) 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. + */ +int device_add_cdev(struct device *parent, struct cdev *cdev) +{ + cdev->kobj.parent = &parent->kobj; + return cdev_add(cdev, parent->devt, 1); +} + static void cdev_unmap(dev_t dev, unsigned count) { kobj_unmap(cdev_map, dev, count); @@ -570,5 +593,6 @@ EXPORT_SYMBOL(cdev_init); EXPORT_SYMBOL(cdev_alloc); EXPORT_SYMBOL(cdev_del); EXPORT_SYMBOL(cdev_add); +EXPORT_SYMBOL(device_add_cdev); EXPORT_SYMBOL(__register_chrdev); EXPORT_SYMBOL(__unregister_chrdev); diff --git a/include/linux/cdev.h b/include/linux/cdev.h index f876361..9edbc37 100644 --- a/include/linux/cdev.h +++ b/include/linux/cdev.h @@ -25,6 +25,7 @@ struct cdev *cdev_alloc(void); void cdev_put(struct cdev *p); int cdev_add(struct cdev *, dev_t, unsigned); +int device_add_cdev(struct device *parent, struct cdev *cdev); void cdev_del(struct cdev *);