All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Daniel Vetter <daniel@ffwll.ch>, Nadav Amit <namit@vmware.com>,
	"VMware, Inc." <pv-drivers@vmware.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: [PATCH 4/9] drm: remove the drm file system
Date: Tue,  9 Mar 2021 16:53:43 +0100	[thread overview]
Message-ID: <20210309155348.974875-5-hch@lst.de> (raw)
In-Reply-To: <20210309155348.974875-1-hch@lst.de>

Just use the generic anon_inode file system.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/drm_drv.c | 64 ++-------------------------------------
 1 file changed, 3 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 87e7214a8e3565..af293d76f979e5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -26,6 +26,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/debugfs.h>
 #include <linux/fs.h>
 #include <linux/module.h>
@@ -475,65 +476,6 @@ void drm_dev_unplug(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_dev_unplug);
 
-/*
- * 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 int drm_fs_init_fs_context(struct fs_context *fc)
-{
-	return init_pseudo(fc, 0x010203ff) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type drm_fs_type = {
-	.name		= "drm",
-	.owner		= THIS_MODULE,
-	.init_fs_context = drm_fs_init_fs_context,
-	.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_sb(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);
-	}
-}
-
 /**
  * DOC: component helper usage recommendations
  *
@@ -563,7 +505,7 @@ static void drm_dev_init_release(struct drm_device *dev, void *res)
 {
 	drm_legacy_ctxbitmap_cleanup(dev);
 	drm_legacy_remove_map_hash(dev);
-	drm_fs_inode_free(dev->anon_inode);
+	iput(dev->anon_inode);
 
 	put_device(dev->dev);
 	/* Prevent use-after-free in drm_managed_release when debugging is
@@ -616,7 +558,7 @@ static int drm_dev_init(struct drm_device *dev,
 	if (ret)
 		return ret;
 
-	dev->anon_inode = drm_fs_inode_new();
+	dev->anon_inode = alloc_anon_inode();
 	if (IS_ERR(dev->anon_inode)) {
 		ret = PTR_ERR(dev->anon_inode);
 		DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
-- 
2.30.1


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	David Hildenbrand <david@redhat.com>,
	"VMware, Inc." <pv-drivers@vmware.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	Minchan Kim <minchan@kernel.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Nadav Amit <namit@vmware.com>, Daniel Vetter <daniel@ffwll.ch>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Nitin Gupta <ngupta@vflare.org>
Subject: [PATCH 4/9] drm: remove the drm file system
Date: Tue,  9 Mar 2021 16:53:43 +0100	[thread overview]
Message-ID: <20210309155348.974875-5-hch@lst.de> (raw)
In-Reply-To: <20210309155348.974875-1-hch@lst.de>

Just use the generic anon_inode file system.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/drm_drv.c | 64 ++-------------------------------------
 1 file changed, 3 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 87e7214a8e3565..af293d76f979e5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -26,6 +26,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/debugfs.h>
 #include <linux/fs.h>
 #include <linux/module.h>
@@ -475,65 +476,6 @@ void drm_dev_unplug(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_dev_unplug);
 
-/*
- * 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 int drm_fs_init_fs_context(struct fs_context *fc)
-{
-	return init_pseudo(fc, 0x010203ff) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type drm_fs_type = {
-	.name		= "drm",
-	.owner		= THIS_MODULE,
-	.init_fs_context = drm_fs_init_fs_context,
-	.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_sb(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);
-	}
-}
-
 /**
  * DOC: component helper usage recommendations
  *
@@ -563,7 +505,7 @@ static void drm_dev_init_release(struct drm_device *dev, void *res)
 {
 	drm_legacy_ctxbitmap_cleanup(dev);
 	drm_legacy_remove_map_hash(dev);
-	drm_fs_inode_free(dev->anon_inode);
+	iput(dev->anon_inode);
 
 	put_device(dev->dev);
 	/* Prevent use-after-free in drm_managed_release when debugging is
@@ -616,7 +558,7 @@ static int drm_dev_init(struct drm_device *dev,
 	if (ret)
 		return ret;
 
-	dev->anon_inode = drm_fs_inode_new();
+	dev->anon_inode = alloc_anon_inode();
 	if (IS_ERR(dev->anon_inode)) {
 		ret = PTR_ERR(dev->anon_inode);
 		DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
-- 
2.30.1


WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	"VMware, Inc." <pv-drivers@vmware.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
	Minchan Kim <minchan@kernel.org>, Nadav Amit <namit@vmware.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Nitin Gupta <ngupta@vflare.org>
Subject: [PATCH 4/9] drm: remove the drm file system
Date: Tue,  9 Mar 2021 16:53:43 +0100	[thread overview]
Message-ID: <20210309155348.974875-5-hch@lst.de> (raw)
In-Reply-To: <20210309155348.974875-1-hch@lst.de>

Just use the generic anon_inode file system.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/gpu/drm/drm_drv.c | 64 ++-------------------------------------
 1 file changed, 3 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 87e7214a8e3565..af293d76f979e5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -26,6 +26,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include <linux/anon_inodes.h>
 #include <linux/debugfs.h>
 #include <linux/fs.h>
 #include <linux/module.h>
@@ -475,65 +476,6 @@ void drm_dev_unplug(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_dev_unplug);
 
-/*
- * 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 int drm_fs_init_fs_context(struct fs_context *fc)
-{
-	return init_pseudo(fc, 0x010203ff) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type drm_fs_type = {
-	.name		= "drm",
-	.owner		= THIS_MODULE,
-	.init_fs_context = drm_fs_init_fs_context,
-	.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_sb(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);
-	}
-}
-
 /**
  * DOC: component helper usage recommendations
  *
@@ -563,7 +505,7 @@ static void drm_dev_init_release(struct drm_device *dev, void *res)
 {
 	drm_legacy_ctxbitmap_cleanup(dev);
 	drm_legacy_remove_map_hash(dev);
-	drm_fs_inode_free(dev->anon_inode);
+	iput(dev->anon_inode);
 
 	put_device(dev->dev);
 	/* Prevent use-after-free in drm_managed_release when debugging is
@@ -616,7 +558,7 @@ static int drm_dev_init(struct drm_device *dev,
 	if (ret)
 		return ret;
 
-	dev->anon_inode = drm_fs_inode_new();
+	dev->anon_inode = alloc_anon_inode();
 	if (IS_ERR(dev->anon_inode)) {
 		ret = PTR_ERR(dev->anon_inode);
 		DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
-- 
2.30.1

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2021-03-09 15:56 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 15:53 make alloc_anon_inode more useful Christoph Hellwig
2021-03-09 15:53 ` Christoph Hellwig
2021-03-09 15:53 ` Christoph Hellwig
2021-03-09 15:53 ` [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 16:21   ` David Hildenbrand
2021-03-09 16:21     ` David Hildenbrand
2021-03-09 16:21     ` David Hildenbrand
2021-03-09 16:21     ` David Hildenbrand
2021-03-09 19:33   ` Gao Xiang
2021-03-09 19:33     ` Gao Xiang
2021-03-09 19:33     ` Gao Xiang
2021-03-09 22:47   ` kernel test robot
2021-03-10  6:39   ` Minchan Kim
2021-03-10  6:39     ` Minchan Kim
2021-03-10  6:39     ` Minchan Kim
2021-03-10  6:39     ` Minchan Kim
2021-03-10  8:30     ` Christoph Hellwig
2021-03-10  8:30       ` Christoph Hellwig
2021-03-10  8:30       ` Christoph Hellwig
2021-03-10  9:33   ` Christian Brauner
2021-03-10  9:33     ` Christian Brauner
2021-03-10  9:33     ` Christian Brauner
2021-03-09 15:53 ` [PATCH 2/9] fs: add an argument-less alloc_anon_inode Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 16:22   ` David Hildenbrand
2021-03-09 16:22     ` David Hildenbrand
2021-03-09 16:22     ` David Hildenbrand
2021-03-09 16:22     ` David Hildenbrand
2021-03-09 19:34   ` Gao Xiang
2021-03-09 19:34     ` Gao Xiang
2021-03-09 19:34     ` Gao Xiang
2021-03-10  9:35   ` Christian Brauner
2021-03-10  9:35     ` Christian Brauner
2021-03-10  9:35     ` Christian Brauner
2021-03-09 15:53 ` [PATCH 3/9] powerpc/pseries: remove the ppc-cmm file system Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 16:26   ` David Hildenbrand
2021-03-09 16:26     ` David Hildenbrand
2021-03-09 16:26     ` David Hildenbrand
2021-03-09 16:26     ` David Hildenbrand
2021-03-09 16:30   ` Jason Gunthorpe
2021-03-09 16:30     ` Jason Gunthorpe
2021-03-09 16:30     ` Jason Gunthorpe
2021-03-10 16:29   ` Al Viro
2021-03-10 16:29     ` Al Viro
2021-03-10 16:29     ` Al Viro
2021-03-10 16:29     ` Al Viro
2021-03-11  8:42     ` Christoph Hellwig
2021-03-11  8:42       ` Christoph Hellwig
2021-03-11  8:42       ` Christoph Hellwig
2021-03-09 15:53 ` Christoph Hellwig [this message]
2021-03-09 15:53   ` [PATCH 4/9] drm: remove the drm " Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-10 16:32   ` Al Viro
2021-03-10 16:32     ` Al Viro
2021-03-10 16:32     ` Al Viro
2021-03-10 16:32     ` Al Viro
2021-03-11  8:35     ` Christoph Hellwig
2021-03-11  8:35       ` Christoph Hellwig
2021-03-11  8:35       ` Christoph Hellwig
2021-03-09 15:53 ` [PATCH 5/9] vmw_balloon: remove the balloon-vmware " Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 16:28   ` David Hildenbrand
2021-03-09 16:28     ` David Hildenbrand
2021-03-09 16:28     ` David Hildenbrand
2021-03-09 16:28     ` David Hildenbrand
2021-03-09 15:53 ` [PATCH 6/9] virtio_balloon: remove the balloon-kvm " Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 16:29   ` David Hildenbrand
2021-03-09 16:29     ` David Hildenbrand
2021-03-09 16:29     ` David Hildenbrand
2021-03-09 16:29     ` David Hildenbrand
2021-03-09 15:53 ` [PATCH 7/9] iomem: remove the iomem " Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-14 13:55   ` [iomem] e14497b88f: BUG:KASAN:null-ptr-deref_in_alloc_anon_inode kernel test robot
2021-03-14 13:55     ` kernel test robot
2021-03-14 13:55     ` kernel test robot
2021-03-14 13:55     ` kernel test robot
2021-03-09 15:53 ` [PATCH 8/9] z3fold: remove the z3fold file system Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53 ` [PATCH 9/9] zsmalloc: remove the zsmalloc " Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-09 15:53   ` Christoph Hellwig
2021-03-10  6:44   ` Minchan Kim
2021-03-10  6:44     ` Minchan Kim
2021-03-10  6:44     ` Minchan Kim
2021-03-10  6:44     ` Minchan Kim
2021-03-09 16:54 ` make alloc_anon_inode more useful Jason Gunthorpe
2021-03-09 16:54   ` Jason Gunthorpe
2021-03-09 16:54   ` Jason Gunthorpe
2021-03-10  8:32   ` Christoph Hellwig
2021-03-10  8:32     ` Christoph Hellwig
2021-03-10  8:32     ` Christoph Hellwig
2021-03-10  4:05 ` Matthew Wilcox
2021-03-10  4:05   ` Matthew Wilcox
2021-03-10  4:05   ` Matthew Wilcox
2021-03-10  4:05   ` Matthew Wilcox
2021-03-10  8:37   ` Christoph Hellwig
2021-03-10  8:37     ` Christoph Hellwig
2021-03-10  8:37     ` Christoph Hellwig
2023-02-03  9:49 ` Jingbo Xu
2023-02-03  9:49   ` Jingbo Xu
2023-02-03  9:49   ` Jingbo Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210309155348.974875-5-hch@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=david@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=minchan@kernel.org \
    --cc=mst@redhat.com \
    --cc=namit@vmware.com \
    --cc=ngupta@vflare.org \
    --cc=pv-drivers@vmware.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.