From: "Michael S. Tsirkin" <mst@redhat.com>
To: kernel test robot <lkp@intel.com>
Cc: Carlos Bilbao <cbilbao@digitalocean.com>,
oe-kbuild-all@lists.linux.dev,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [linux-next:master 9473/10190] drivers/vdpa/mlx5/net/mlx5_vnet.c:3910:24: sparse: sparse: incorrect type in assignment (different base types)
Date: Thu, 7 Nov 2024 16:48:37 -0500 [thread overview]
Message-ID: <20241107164504-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <202411080535.Xq60FSHw-lkp@intel.com>
I dropped the patch for now, I think it's wrong. CB.
On Fri, Nov 08, 2024 at 05:34:27AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 74741a050b79d31d8d2eeee12c77736596d0a6b2
> commit: 09e317f5d07e3fb5bc09674eb94e38e138fef4bf [9473/10190] vdpa/mlx5: Set speed and duplex of vDPA devices to UNKNOWN
> config: i386-randconfig-061-20241107 (https://download.01.org/0day-ci/archive/20241108/202411080535.Xq60FSHw-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241108/202411080535.Xq60FSHw-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202411080535.Xq60FSHw-lkp@intel.com/
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/vdpa/mlx5/net/mlx5_vnet.c:3910:24: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] speed @@ got restricted __virtio32 @@
> drivers/vdpa/mlx5/net/mlx5_vnet.c:3910:24: sparse: expected restricted __le32 [usertype] speed
> drivers/vdpa/mlx5/net/mlx5_vnet.c:3910:24: sparse: got restricted __virtio32
>
> vim +3910 drivers/vdpa/mlx5/net/mlx5_vnet.c
>
> 3822
> 3823 static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
> 3824 const struct vdpa_dev_set_config *add_config)
> 3825 {
> 3826 struct mlx5_vdpa_mgmtdev *mgtdev = container_of(v_mdev, struct mlx5_vdpa_mgmtdev, mgtdev);
> 3827 struct virtio_net_config *config;
> 3828 struct mlx5_core_dev *pfmdev;
> 3829 struct mlx5_vdpa_dev *mvdev;
> 3830 struct mlx5_vdpa_net *ndev;
> 3831 struct mlx5_core_dev *mdev;
> 3832 u64 device_features;
> 3833 u32 max_vqs;
> 3834 u16 mtu;
> 3835 int err;
> 3836
> 3837 if (mgtdev->ndev)
> 3838 return -ENOSPC;
> 3839
> 3840 mdev = mgtdev->madev->mdev;
> 3841 device_features = mgtdev->mgtdev.supported_features;
> 3842 if (add_config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) {
> 3843 if (add_config->device_features & ~device_features) {
> 3844 dev_warn(mdev->device,
> 3845 "The provisioned features 0x%llx are not supported by this device with features 0x%llx\n",
> 3846 add_config->device_features, device_features);
> 3847 return -EINVAL;
> 3848 }
> 3849 device_features &= add_config->device_features;
> 3850 } else {
> 3851 device_features &= ~BIT_ULL(VIRTIO_NET_F_MRG_RXBUF);
> 3852 }
> 3853 if (!(device_features & BIT_ULL(VIRTIO_F_VERSION_1) &&
> 3854 device_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM))) {
> 3855 dev_warn(mdev->device,
> 3856 "Must provision minimum features 0x%llx for this device",
> 3857 BIT_ULL(VIRTIO_F_VERSION_1) | BIT_ULL(VIRTIO_F_ACCESS_PLATFORM));
> 3858 return -EOPNOTSUPP;
> 3859 }
> 3860
> 3861 if (!(MLX5_CAP_DEV_VDPA_EMULATION(mdev, virtio_queue_type) &
> 3862 MLX5_VIRTIO_EMULATION_CAP_VIRTIO_QUEUE_TYPE_SPLIT)) {
> 3863 dev_warn(mdev->device, "missing support for split virtqueues\n");
> 3864 return -EOPNOTSUPP;
> 3865 }
> 3866
> 3867 max_vqs = min_t(int, MLX5_CAP_DEV_VDPA_EMULATION(mdev, max_num_virtio_queues),
> 3868 1 << MLX5_CAP_GEN(mdev, log_max_rqt_size));
> 3869 if (max_vqs < 2) {
> 3870 dev_warn(mdev->device,
> 3871 "%d virtqueues are supported. At least 2 are required\n",
> 3872 max_vqs);
> 3873 return -EAGAIN;
> 3874 }
> 3875
> 3876 if (add_config->mask & BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MAX_VQP)) {
> 3877 if (add_config->net.max_vq_pairs > max_vqs / 2)
> 3878 return -EINVAL;
> 3879 max_vqs = min_t(u32, max_vqs, 2 * add_config->net.max_vq_pairs);
> 3880 } else {
> 3881 max_vqs = 2;
> 3882 }
> 3883
> 3884 ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, mdev->device, &mgtdev->vdpa_ops,
> 3885 MLX5_VDPA_NUMVQ_GROUPS, MLX5_VDPA_NUM_AS, name, false);
> 3886 if (IS_ERR(ndev))
> 3887 return PTR_ERR(ndev);
> 3888
> 3889 ndev->mvdev.max_vqs = max_vqs;
> 3890 mvdev = &ndev->mvdev;
> 3891 mvdev->mdev = mdev;
> 3892
> 3893 ndev->vqs = kcalloc(max_vqs, sizeof(*ndev->vqs), GFP_KERNEL);
> 3894 ndev->event_cbs = kcalloc(max_vqs + 1, sizeof(*ndev->event_cbs), GFP_KERNEL);
> 3895 if (!ndev->vqs || !ndev->event_cbs) {
> 3896 err = -ENOMEM;
> 3897 goto err_alloc;
> 3898 }
> 3899 ndev->cur_num_vqs = MLX5V_DEFAULT_VQ_COUNT;
> 3900
> 3901 mvqs_set_defaults(ndev);
> 3902 allocate_irqs(ndev);
> 3903 init_rwsem(&ndev->reslock);
> 3904 config = &ndev->config;
> 3905
> 3906 /*
> 3907 * mlx5_vdpa vDPA devices currently don't support reporting or
> 3908 * setting the speed or duplex.
> 3909 */
> > 3910 config->speed = cpu_to_mlx5vdpa32(mvdev, SPEED_UNKNOWN);
> 3911 config->duplex = DUPLEX_UNKNOWN;
Looking at this in more detail, so
1. why not just clear the feature bits?
2. you should not expose SPEED_UNKNOWN in UAPI, it happens to work but
really there's no intent to devices to actually say "I do not know
the duplex" - unknown here was intended so we can later add
new values and userspace will say "I don't know how to interpret it"
rather than crashing. Same for duplex.
> 3912
> 3913 if (add_config->mask & BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MTU)) {
> 3914 err = config_func_mtu(mdev, add_config->net.mtu);
> 3915 if (err)
> 3916 goto err_alloc;
> 3917 }
> 3918
> 3919 if (device_features & BIT_ULL(VIRTIO_NET_F_MTU)) {
> 3920 err = query_mtu(mdev, &mtu);
> 3921 if (err)
> 3922 goto err_alloc;
> 3923
> 3924 ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, mtu);
> 3925 }
> 3926
> 3927 if (device_features & BIT_ULL(VIRTIO_NET_F_STATUS)) {
> 3928 if (get_link_state(mvdev))
> 3929 ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP);
> 3930 else
> 3931 ndev->config.status &= cpu_to_mlx5vdpa16(mvdev, ~VIRTIO_NET_S_LINK_UP);
> 3932 }
> 3933
> 3934 if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> 3935 memcpy(ndev->config.mac, add_config->net.mac, ETH_ALEN);
> 3936 /* No bother setting mac address in config if not going to provision _F_MAC */
> 3937 } else if ((add_config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) == 0 ||
> 3938 device_features & BIT_ULL(VIRTIO_NET_F_MAC)) {
> 3939 err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
> 3940 if (err)
> 3941 goto err_alloc;
> 3942 }
> 3943
> 3944 if (!is_zero_ether_addr(config->mac)) {
> 3945 pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> 3946 err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> 3947 if (err)
> 3948 goto err_alloc;
> 3949 } else if ((add_config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) == 0) {
> 3950 /*
> 3951 * We used to clear _F_MAC feature bit if seeing
> 3952 * zero mac address when device features are not
> 3953 * specifically provisioned. Keep the behaviour
> 3954 * so old scripts do not break.
> 3955 */
> 3956 device_features &= ~BIT_ULL(VIRTIO_NET_F_MAC);
> 3957 } else if (device_features & BIT_ULL(VIRTIO_NET_F_MAC)) {
> 3958 /* Don't provision zero mac address for _F_MAC */
> 3959 mlx5_vdpa_warn(&ndev->mvdev,
> 3960 "No mac address provisioned?\n");
> 3961 err = -EINVAL;
> 3962 goto err_alloc;
> 3963 }
> 3964
> 3965 if (device_features & BIT_ULL(VIRTIO_NET_F_MQ)) {
> 3966 config->max_virtqueue_pairs = cpu_to_mlx5vdpa16(mvdev, max_vqs / 2);
> 3967 ndev->rqt_size = max_vqs / 2;
> 3968 } else {
> 3969 ndev->rqt_size = 1;
> 3970 }
> 3971
> 3972 mlx5_cmd_init_async_ctx(mdev, &mvdev->async_ctx);
> 3973
> 3974 ndev->mvdev.mlx_features = device_features;
> 3975 mvdev->vdev.dma_dev = &mdev->pdev->dev;
> 3976 err = mlx5_vdpa_alloc_resources(&ndev->mvdev);
> 3977 if (err)
> 3978 goto err_alloc;
> 3979
> 3980 err = mlx5_vdpa_init_mr_resources(mvdev);
> 3981 if (err)
> 3982 goto err_alloc;
> 3983
> 3984 if (MLX5_CAP_GEN(mvdev->mdev, umem_uid_0)) {
> 3985 err = mlx5_vdpa_create_dma_mr(mvdev);
> 3986 if (err)
> 3987 goto err_alloc;
> 3988 }
> 3989
> 3990 err = alloc_fixed_resources(ndev);
> 3991 if (err)
> 3992 goto err_alloc;
> 3993
> 3994 ndev->cvq_ent.mvdev = mvdev;
> 3995 INIT_WORK(&ndev->cvq_ent.work, mlx5_cvq_kick_handler);
> 3996 mvdev->wq = create_singlethread_workqueue("mlx5_vdpa_wq");
> 3997 if (!mvdev->wq) {
> 3998 err = -ENOMEM;
> 3999 goto err_alloc;
> 4000 }
> 4001
> 4002 mvdev->vdev.mdev = &mgtdev->mgtdev;
> 4003 err = _vdpa_register_device(&mvdev->vdev, max_vqs + 1);
> 4004 if (err)
> 4005 goto err_reg;
> 4006
> 4007 mgtdev->ndev = ndev;
> 4008
> 4009 /* For virtio-vdpa, the device was set up during device register. */
> 4010 if (ndev->setup)
> 4011 return 0;
> 4012
> 4013 down_write(&ndev->reslock);
> 4014 err = setup_vq_resources(ndev, false);
> 4015 up_write(&ndev->reslock);
> 4016 if (err)
> 4017 goto err_setup_vq_res;
> 4018
> 4019 return 0;
> 4020
> 4021 err_setup_vq_res:
> 4022 _vdpa_unregister_device(&mvdev->vdev);
> 4023 err_reg:
> 4024 destroy_workqueue(mvdev->wq);
> 4025 err_alloc:
> 4026 put_device(&mvdev->vdev.dev);
> 4027 return err;
> 4028 }
> 4029
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
prev parent reply other threads:[~2024-11-07 21:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 21:34 [linux-next:master 9473/10190] drivers/vdpa/mlx5/net/mlx5_vnet.c:3910:24: sparse: sparse: incorrect type in assignment (different base types) kernel test robot
2024-11-07 21:42 ` Michael S. Tsirkin
2024-11-07 21:48 ` Michael S. Tsirkin [this message]
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=20241107164504-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cbilbao@digitalocean.com \
--cc=dtatulea@nvidia.com \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
/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.