From patchwork Thu Jan 23 12:38:37 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Herrmann X-Patchwork-Id: 3528351 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 0FC9A9F1C3 for ; Thu, 23 Jan 2014 12:39:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B7BE920173 for ; Thu, 23 Jan 2014 12:39:12 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id A1007200FF for ; Thu, 23 Jan 2014 12:39:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3D00CFBF17; Thu, 23 Jan 2014 04:39:07 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by gabe.freedesktop.org (Postfix) with ESMTP id E3551FBF17 for ; Thu, 23 Jan 2014 04:39:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id q58so1089466wes.17 for ; Thu, 23 Jan 2014 04:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=goEUoXkXyjn4DFJ3EzFGmIKyADkkTDn3aJGk/p3xn5Q=; b=Ye+eKAy9lPJC1VrbvJ5YYGy5L0+gYimToaVQlgdJ2Skh6692zej2Ab0h+VXv0PB+CK brbxC0ECuU1fKm8FrD90tOX4KrCJjOfV7O+DSex87tgNI4Js192wxeQA2qIuSlCcCQ5j Npm8Zdusiyaz3fBDKlFd1kDMxaSfrQUU+jUMR6wTWt2ks24N5PCF4TxjKwXCJQsyWRQy dWCnpB2ttvr3Axj0PeEqAA19mHWsXaThkRH95AptnQMrZHOWjZf02n5+LFfcSUfMctkH SjmFM6pCnpJ6MChYqDGnF7xswJY7z9mTk4VOrungpivf3Haw6TU6VBaYO5tLQnzdwx/g hivA== X-Received: by 10.194.2.110 with SMTP id 14mr82217wjt.96.1390480742782; Thu, 23 Jan 2014 04:39:02 -0800 (PST) Received: from david-ub.localdomain (stgt-5f71be19.pool.mediaWays.net. [95.113.190.25]) by mx.google.com with ESMTPSA id w1sm27484723wib.6.2014.01.23.04.39.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Jan 2014 04:39:01 -0800 (PST) From: David Herrmann To: dri-devel@lists.freedesktop.org Subject: [PATCH v3 1/3] drm: add pseudo filesystem for shared inodes Date: Thu, 23 Jan 2014 13:38:37 +0100 Message-Id: <1390480719-434-1-git-send-email-dh.herrmann@gmail.com> X-Mailer: git-send-email 1.8.5.3 Cc: linux-kernel@vger.kernel.org, Al Viro X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Our current DRM design uses a single address_space for all users of the same DRM device. However, there is no way to create an anonymous address_space without an underlying inode. Therefore, we wait for the first ->open() callback on a registered char-dev and take-over the inode of the char-dev. This worked well so far, but has several drawbacks: - We screw with FS internals and rely on some non-obvious invariants like inode->i_mapping being the same as inode->i_data for char-devs. - We don't have any address_space prior to the first ->open() from user-space. This leads to ugly fallback code and we cannot allocate global objects early. As pointed out by Al-Viro, fs/anon_inode.c is *not* supposed to be used by drivers for anonymous inode-allocation. Therefore, this patch follows the proposed alternative solution and adds a pseudo filesystem mount-point to DRM. We can then allocate private inodes including a private address_space for each DRM device at initialization time. Note that we could use: sysfs_get_inode(sysfs_mnt->mnt_sb, drm_device->dev->kobj.sd); to get access to the underlying sysfs-inode of a "struct device" object. However, most of this information is currently hidden and it's not clear whether this address_space is suitable for driver access. Thus, unless linux allows anonymous address_space objects or driver-core provides a public inode per device, we're left with our own private internal mount point. Cc: Al Viro Signed-off-by: David Herrmann --- v3: - Move all stuff to drm_stub.c so we don't have to export it - Make drm.ko unloading work by switching to simple_pin_fs() instead of kern_mount(). Hey guys So this is v3, this time with dynamic mount management. Downside is, if external code takes a reference to our inodes, we *may* end up with multiple internal vfsmounts during device hotplugging. However, this requires that there's a timespan where *no* DRM device is registered. But the actualy downside is just more memory-consumption, so this seems fine. Comments welcome! Tested with i915 and nouveau. Thanks David drivers/gpu/drm/drm_stub.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index 98a33c580..f2903d7 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -31,8 +31,10 @@ * DEALINGS IN THE SOFTWARE. */ +#include #include #include +#include #include #include #include @@ -416,6 +418,78 @@ void drm_unplug_dev(struct drm_device *dev) } EXPORT_SYMBOL(drm_unplug_dev); +/* + * DRM internal mount + * We want to be able to allocate our own "struct address_space" to control + * memory-mappings in VRAM (or stolen RAM, ...). However, core MM does not allow + * stand-alone address_space objects, so we need an underlying inode. As there + * is no way to allocate an independent inode easily, we need a fake internal + * VFS mount-point. + * + * The drm_fs_inode_new() function allocates a new inode, drm_fs_inode_free() + * frees it again. You are allowed to use iget() and iput() to get references to + * the inode. But each drm_fs_inode_new() call must be paired with exactly one + * drm_fs_inode_free() call (which does not have to be the last iput()). + * We use drm_fs_inode_*() to manage our internal VFS mount-point and share it + * between multiple inode-users. You could, technically, call + * iget() + drm_fs_inode_free() directly after alloc and sometime later do an + * iput(), but this way you'd end up with a new vfsmount for each inode. + */ + +static int drm_fs_cnt; +static struct vfsmount *drm_fs_mnt; + +static const struct dentry_operations drm_fs_dops = { + .d_dname = simple_dname, +}; + +static const struct super_operations drm_fs_sops = { + .statfs = simple_statfs, +}; + +static struct dentry *drm_fs_mount(struct file_system_type *fs_type, int flags, + const char *dev_name, void *data) +{ + return mount_pseudo(fs_type, + "drm:", + &drm_fs_sops, + &drm_fs_dops, + 0x010203ff); +} + +static struct file_system_type drm_fs_type = { + .name = "drm", + .owner = THIS_MODULE, + .mount = drm_fs_mount, + .kill_sb = kill_anon_super, +}; + +static struct inode *drm_fs_inode_new(void) +{ + struct inode *inode; + int r; + + r = simple_pin_fs(&drm_fs_type, &drm_fs_mnt, &drm_fs_cnt); + if (r < 0) { + DRM_ERROR("Cannot mount pseudo fs: %d\n", r); + return ERR_PTR(r); + } + + inode = alloc_anon_inode(drm_fs_mnt->mnt_sb); + if (IS_ERR(inode)) + simple_release_fs(&drm_fs_mnt, &drm_fs_cnt); + + return inode; +} + +static void drm_fs_inode_free(struct inode *inode) +{ + if (inode) { + iput(inode); + simple_release_fs(&drm_fs_mnt, &drm_fs_cnt); + } +} + /** * drm_dev_alloc - Allocate new drm device * @driver: DRM driver to allocate device for