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
next prev 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).