kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Xie Yongji <xieyongji@bytedance.com>
Cc: mst@redhat.com, jasowang@redhat.com, stefanha@redhat.com,
	sgarzare@redhat.com, parav@nvidia.com, hch@infradead.org,
	christian.brauner@canonical.com, rdunlap@infradead.org,
	willy@infradead.org, viro@zeniv.linux.org.uk, axboe@kernel.dk,
	bcrl@kvack.org, corbet@lwn.net, mika.penttila@nextfour.com,
	dan.carpenter@oracle.com, joro@8bytes.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, kvm@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, iommu@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace
Date: Mon, 31 May 2021 06:56:26 +0200	[thread overview]
Message-ID: <YLRsehBRAiCJEDl0@kroah.com> (raw)
In-Reply-To: <20210517095513.850-12-xieyongji@bytedance.com>

On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> +struct vduse_dev {
> +	struct vduse_vdpa *vdev;
> +	struct device dev;
> +	struct cdev cdev;

You now have 2 reference counted devices controling the lifespace of a
single structure.  A mess that is guaranteed to go wrong.  Please never
do this.

> +	struct vduse_virtqueue *vqs;
> +	struct vduse_iova_domain *domain;
> +	char *name;
> +	struct mutex lock;
> +	spinlock_t msg_lock;
> +	atomic64_t msg_unique;

Why do you need an atomic and a lock?

> +	wait_queue_head_t waitq;
> +	struct list_head send_list;
> +	struct list_head recv_list;
> +	struct list_head list;
> +	struct vdpa_callback config_cb;
> +	struct work_struct inject;
> +	spinlock_t irq_lock;
> +	unsigned long api_version;
> +	bool connected;
> +	int minor;
> +	u16 vq_size_max;
> +	u32 vq_num;
> +	u32 vq_align;
> +	u32 config_size;
> +	u32 device_id;
> +	u32 vendor_id;
> +};
> +
> +struct vduse_dev_msg {
> +	struct vduse_dev_request req;
> +	struct vduse_dev_response resp;
> +	struct list_head list;
> +	wait_queue_head_t waitq;
> +	bool completed;
> +};
> +
> +struct vduse_control {
> +	unsigned long api_version;

u64?

> +};
> +
> +static unsigned long max_bounce_size = (64 * 1024 * 1024);
> +module_param(max_bounce_size, ulong, 0444);
> +MODULE_PARM_DESC(max_bounce_size, "Maximum bounce buffer size. (default: 64M)");
> +
> +static unsigned long max_iova_size = (128 * 1024 * 1024);
> +module_param(max_iova_size, ulong, 0444);
> +MODULE_PARM_DESC(max_iova_size, "Maximum iova space size (default: 128M)");
> +
> +static bool allow_unsafe_device_emulation;
> +module_param(allow_unsafe_device_emulation, bool, 0444);
> +MODULE_PARM_DESC(allow_unsafe_device_emulation, "Allow emulating unsafe device."
> +	" We must make sure the userspace device emulation process is trusted."
> +	" Otherwise, don't enable this option. (default: false)");
> +

This is not the 1990's anymore, please never use module parameters, make
these per-device attributes if you really need them.

> +static int vduse_init(void)
> +{
> +	int ret;
> +
> +	if (max_bounce_size >= max_iova_size)
> +		return -EINVAL;
> +
> +	ret = misc_register(&vduse_misc);
> +	if (ret)
> +		return ret;
> +
> +	vduse_class = class_create(THIS_MODULE, "vduse");

If you have a misc device, you do not need to create a class at the same
time.  Why are you doing both here?  Just stick with the misc device, no
need for anything else.

> +	if (IS_ERR(vduse_class)) {
> +		ret = PTR_ERR(vduse_class);
> +		goto err_class;
> +	}
> +	vduse_class->devnode = vduse_devnode;
> +
> +	ret = alloc_chrdev_region(&vduse_major, 0, VDUSE_DEV_MAX, "vduse");

Wait, you want a whole major?  What is the misc device for?

> +MODULE_VERSION(DRV_VERSION);

MODULE_VERSION() makes no sense when the code is merged into the kernel
tree, so you can just drop that.

thanks,

greg k-h

  parent reply	other threads:[~2021-05-31  4:56 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  9:55 [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-05-17  9:55 ` [PATCH v7 01/12] iova: Export alloc_iova_fast() Xie Yongji
2021-05-26  2:36   ` Jason Wang
2021-05-26  2:43     ` Yongji Xie
2021-05-17  9:55 ` [PATCH v7 02/12] file: Export receive_fd() to modules Xie Yongji
2021-05-20  6:18   ` Al Viro
2021-05-20  6:32     ` Yongji Xie
2021-05-17  9:55 ` [PATCH v7 03/12] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
2021-05-17  9:55 ` [PATCH v7 04/12] virtio-blk: Add validation for block size in config space Xie Yongji
2021-05-19 13:39   ` Yongji Xie
2021-05-19 14:42     ` Dan Carpenter
2021-05-20  5:25       ` Yongji Xie
2021-05-20  5:43         ` Michael S. Tsirkin
2021-05-20  7:08           ` Yongji Xie
2021-05-17  9:55 ` [PATCH v7 05/12] virtio_scsi: Add validation for residual bytes from response Xie Yongji
2021-05-26  2:41   ` Jason Wang
2021-05-17  9:55 ` [PATCH v7 06/12] vhost-iotlb: Add an opaque pointer for vhost IOTLB Xie Yongji
2021-05-17  9:55 ` [PATCH v7 07/12] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
2021-05-17  9:55 ` [PATCH v7 08/12] vdpa: factor out vhost_vdpa_pa_map() and vhost_vdpa_pa_unmap() Xie Yongji
2021-05-17  9:55 ` [PATCH v7 09/12] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
2021-05-17  9:55 ` [PATCH v7 10/12] vduse: Implement an MMU-based IOMMU driver Xie Yongji
2021-05-17  9:55 ` [PATCH v7 11/12] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-05-20  6:28   ` Al Viro
2021-05-20  7:03     ` Yongji Xie
2021-05-27  4:12   ` Jason Wang
2021-05-27  4:57     ` Yongji Xie
2021-05-27  5:00       ` Jason Wang
2021-05-27  5:08         ` Yongji Xie
2021-05-27  5:40           ` Jason Wang
2021-05-27  7:34             ` Yongji Xie
2021-05-27  8:41               ` Jason Wang
2021-05-27  8:43                 ` Jason Wang
2021-05-27 10:14                   ` Yongji Xie
2021-05-28  1:33                     ` Jason Wang
2021-05-28  3:54                       ` Yongji Xie
2021-05-28  6:38                         ` Jason Wang
2021-05-27 13:17                 ` Yongji Xie
2021-05-28  2:31                   ` Jason Wang
2021-05-31  4:27                     ` Yongji Xie
2021-05-31  4:38                       ` Jason Wang
2021-05-31  6:24                         ` Yongji Xie
2021-05-31  4:56   ` Greg KH [this message]
2021-05-31  6:19     ` Yongji Xie
2021-05-31  6:32       ` Greg KH
2021-05-31  7:13         ` Yongji Xie
2021-05-17  9:55 ` [PATCH v7 12/12] Documentation: Add documentation for VDUSE Xie Yongji
2021-05-20  6:06 ` [PATCH v7 00/12] Introduce VDUSE - vDPA Device in Userspace Michael S. Tsirkin
2021-05-20  9:06   ` Yongji Xie
2021-05-25  6:40     ` Jason Wang
2021-05-25  6:48       ` Michael S. Tsirkin
2021-05-25  7:11         ` Jason Wang

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=YLRsehBRAiCJEDl0@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=axboe@kernel.dk \
    --cc=bcrl@kvack.org \
    --cc=christian.brauner@canonical.com \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jasowang@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.penttila@nextfour.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=rdunlap@infradead.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=xieyongji@bytedance.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).