linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: mst@redhat.com, xuanzhuo@linux.alibaba.com, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	xieyongji@bytedance.com,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	david.marchand@redhat.com, lulu@redhat.com,
	casey@schaufler-ca.com
Subject: Re: [PATCH v5 2/4] vduse: Temporarily disable control queue features
Date: Wed, 13 Dec 2023 12:23:35 +0100	[thread overview]
Message-ID: <8afc44f7-cef5-4b4a-afac-85a4eb967d3e@redhat.com> (raw)
In-Reply-To: <CACGkMEthp13a20TGashiFNDovK+b10mgfdX8L=3Xv05g5-eo0w@mail.gmail.com>

Hi Jason,

On 12/13/23 05:52, Jason Wang wrote:
> On Tue, Dec 12, 2023 at 9:17 PM Maxime Coquelin
> <maxime.coquelin@redhat.com> wrote:
>>
>> Virtio-net driver control queue implementation is not safe
>> when used with VDUSE. If the VDUSE application does not
>> reply to control queue messages, it currently ends up
>> hanging the kernel thread sending this command.
>>
>> Some work is on-going to make the control queue
>> implementation robust with VDUSE. Until it is completed,
>> let's disable control virtqueue and features that depend on
>> it.
>>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> 
> I wonder if it's better to fail instead of a mask as a start.

I think it is better to use a mask and not fail, so that we can in the
future use a recent VDUSE application with an older kernel.

Why would it be better to fail than negotiating?

Thanks,
Maxime

> Thanks
> 
>> ---
>>   drivers/vdpa/vdpa_user/vduse_dev.c | 37 ++++++++++++++++++++++++++++++
>>   1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
>> index 0486ff672408..fe4b5c8203fd 100644
>> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
>> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
>> @@ -28,6 +28,7 @@
>>   #include <uapi/linux/virtio_config.h>
>>   #include <uapi/linux/virtio_ids.h>
>>   #include <uapi/linux/virtio_blk.h>
>> +#include <uapi/linux/virtio_ring.h>
>>   #include <linux/mod_devicetable.h>
>>
>>   #include "iova_domain.h"
>> @@ -46,6 +47,30 @@
>>
>>   #define IRQ_UNBOUND -1
>>
>> +#define VDUSE_NET_VALID_FEATURES_MASK           \
>> +       (BIT_ULL(VIRTIO_NET_F_CSUM) |           \
>> +        BIT_ULL(VIRTIO_NET_F_GUEST_CSUM) |     \
>> +        BIT_ULL(VIRTIO_NET_F_MTU) |            \
>> +        BIT_ULL(VIRTIO_NET_F_MAC) |            \
>> +        BIT_ULL(VIRTIO_NET_F_GUEST_TSO4) |     \
>> +        BIT_ULL(VIRTIO_NET_F_GUEST_TSO6) |     \
>> +        BIT_ULL(VIRTIO_NET_F_GUEST_ECN) |      \
>> +        BIT_ULL(VIRTIO_NET_F_GUEST_UFO) |      \
>> +        BIT_ULL(VIRTIO_NET_F_HOST_TSO4) |      \
>> +        BIT_ULL(VIRTIO_NET_F_HOST_TSO6) |      \
>> +        BIT_ULL(VIRTIO_NET_F_HOST_ECN) |       \
>> +        BIT_ULL(VIRTIO_NET_F_HOST_UFO) |       \
>> +        BIT_ULL(VIRTIO_NET_F_MRG_RXBUF) |      \
>> +        BIT_ULL(VIRTIO_NET_F_STATUS) |         \
>> +        BIT_ULL(VIRTIO_NET_F_HOST_USO) |       \
>> +        BIT_ULL(VIRTIO_F_ANY_LAYOUT) |         \
>> +        BIT_ULL(VIRTIO_RING_F_INDIRECT_DESC) | \
>> +        BIT_ULL(VIRTIO_RING_F_EVENT_IDX) |          \
>> +        BIT_ULL(VIRTIO_F_VERSION_1) |          \
>> +        BIT_ULL(VIRTIO_F_ACCESS_PLATFORM) |     \
>> +        BIT_ULL(VIRTIO_F_RING_PACKED) |        \
>> +        BIT_ULL(VIRTIO_F_IN_ORDER))
>> +
>>   struct vduse_virtqueue {
>>          u16 index;
>>          u16 num_max;
>> @@ -1782,6 +1807,16 @@ static struct attribute *vduse_dev_attrs[] = {
>>
>>   ATTRIBUTE_GROUPS(vduse_dev);
>>
>> +static void vduse_dev_features_filter(struct vduse_dev_config *config)
>> +{
>> +       /*
>> +        * Temporarily filter out virtio-net's control virtqueue and features
>> +        * that depend on it while CVQ is being made more robust for VDUSE.
>> +        */
>> +       if (config->device_id == VIRTIO_ID_NET)
>> +               config->features &= VDUSE_NET_VALID_FEATURES_MASK;
>> +}
>> +
>>   static int vduse_create_dev(struct vduse_dev_config *config,
>>                              void *config_buf, u64 api_version)
>>   {
>> @@ -1797,6 +1832,8 @@ static int vduse_create_dev(struct vduse_dev_config *config,
>>          if (!dev)
>>                  goto err;
>>
>> +       vduse_dev_features_filter(config);
>> +
>>          dev->api_version = api_version;
>>          dev->device_features = config->features;
>>          dev->device_id = config->device_id;
>> --
>> 2.43.0
>>
> 


  reply	other threads:[~2023-12-13 11:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 13:17 [PATCH v5 0/4] vduse: add support for networking devices Maxime Coquelin
2023-12-12 13:17 ` [PATCH v5 1/4] vduse: validate block features only with block devices Maxime Coquelin
2023-12-12 13:17 ` [PATCH v5 2/4] vduse: Temporarily disable control queue features Maxime Coquelin
2023-12-13  4:52   ` Jason Wang
2023-12-13 11:23     ` Maxime Coquelin [this message]
2023-12-18  2:50       ` Jason Wang
2023-12-18  9:21         ` Maxime Coquelin
2023-12-20  3:50           ` Jason Wang
2023-12-12 13:17 ` [PATCH v5 3/4] vduse: enable Virtio-net device type Maxime Coquelin
2023-12-12 13:17 ` [PATCH v5 4/4] vduse: Add LSM hook to check Virtio " Maxime Coquelin
2023-12-12 16:33   ` Casey Schaufler
2023-12-12 17:59     ` Michael S. Tsirkin
2023-12-12 22:55       ` Casey Schaufler
2023-12-16  4:18         ` Serge E. Hallyn
2023-12-18 17:21   ` Stephen Smalley
2023-12-18 17:33     ` Stephen Smalley
2024-01-04 10:14       ` Maxime Coquelin
2023-12-19 18:20     ` Paul Moore

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=8afc44f7-cef5-4b4a-afac-85a4eb967d3e@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=david.marchand@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=jasowang@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stephen.smalley.work@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.com \
    --cc=xuanzhuo@linux.alibaba.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).