It's legal to have 'offset + len' equal to
sizeof(struct virtio_net_config), since 'ndev->config' is a
'struct virtio_net_config', so we can safely copy its content under
this condition.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Cc: [email protected]
Signed-off-by: Stefano Garzarella <[email protected]>
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index dc88559a8d49..10e9b09932eb 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
- if (offset + len < sizeof(struct virtio_net_config))
+ if (offset + len <= sizeof(struct virtio_net_config))
memcpy(buf, (u8 *)&ndev->config + offset, len);
}
--
2.29.2
On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> It's legal to have 'offset + len' equal to
> sizeof(struct virtio_net_config), since 'ndev->config' is a
> 'struct virtio_net_config', so we can safely copy its content under
> this condition.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Cc: [email protected]
> Signed-off-by: Stefano Garzarella <[email protected]>
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index dc88559a8d49..10e9b09932eb 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>
> - if (offset + len < sizeof(struct virtio_net_config))
> + if (offset + len <= sizeof(struct virtio_net_config))
> memcpy(buf, (u8 *)&ndev->config + offset, len);
> }
Actually first I am not sure we need these checks at all.
vhost_vdpa_config_validate already validates the values, right?
Second, what will happen when we extend the struct and then
run new userspace on an old kernel? Looks like it will just
fail right? So what is the plan? I think we should
allow a bigger size, and return the copied config size to userspace.
> --
> 2.29.2
On 2021/2/9 上午12:17, Stefano Garzarella wrote:
> It's legal to have 'offset + len' equal to
> sizeof(struct virtio_net_config), since 'ndev->config' is a
> 'struct virtio_net_config', so we can safely copy its content under
> this condition.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Cc: [email protected]
> Signed-off-by: Stefano Garzarella <[email protected]>
Acked-by: Jason Wang <[email protected]>
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index dc88559a8d49..10e9b09932eb 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>
> - if (offset + len < sizeof(struct virtio_net_config))
> + if (offset + len <= sizeof(struct virtio_net_config))
> memcpy(buf, (u8 *)&ndev->config + offset, len);
> }
>
On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
> On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>> It's legal to have 'offset + len' equal to
>> sizeof(struct virtio_net_config), since 'ndev->config' is a
>> 'struct virtio_net_config', so we can safely copy its content under
>> this condition.
>>
>> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
>> Cc: [email protected]
>> Signed-off-by: Stefano Garzarella <[email protected]>
>> ---
>> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> index dc88559a8d49..10e9b09932eb 100644
>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
>> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>>
>> - if (offset + len < sizeof(struct virtio_net_config))
>> + if (offset + len <= sizeof(struct virtio_net_config))
>> memcpy(buf, (u8 *)&ndev->config + offset, len);
>> }
> Actually first I am not sure we need these checks at all.
> vhost_vdpa_config_validate already validates the values, right?
I think they're working at different levels. There's no guarantee that
vhost-vdpa is the driver for this vdpa device.
>
> Second, what will happen when we extend the struct and then
> run new userspace on an old kernel? Looks like it will just
> fail right? So what is the plan?
In this case, get_config() should match the spec behaviour. That is to
say the size of config space depends on the feature negotiated.
Thanks
> I think we should
> allow a bigger size, and return the copied config size to userspace.
>
>
>> --
>> 2.29.2
On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> It's legal to have 'offset + len' equal to
> sizeof(struct virtio_net_config), since 'ndev->config' is a
> 'struct virtio_net_config', so we can safely copy its content under
> this condition.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Cc: [email protected]
> Signed-off-by: Stefano Garzarella <[email protected]>
Acked-by: Eli Cohen <[email protected]>
BTW, same error in vdpa_sim you may want to fix.
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index dc88559a8d49..10e9b09932eb 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>
> - if (offset + len < sizeof(struct virtio_net_config))
> + if (offset + len <= sizeof(struct virtio_net_config))
> memcpy(buf, (u8 *)&ndev->config + offset, len);
> }
>
> --
> 2.29.2
>
On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
>
>On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
>>On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>>>It's legal to have 'offset + len' equal to
>>>sizeof(struct virtio_net_config), since 'ndev->config' is a
>>>'struct virtio_net_config', so we can safely copy its content under
>>>this condition.
>>>
>>>Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
>>>Cc: [email protected]
>>>Signed-off-by: Stefano Garzarella <[email protected]>
>>>---
>>> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>>diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>>index dc88559a8d49..10e9b09932eb 100644
>>>--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>>+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>>@@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
>>> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>>> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>>>- if (offset + len < sizeof(struct virtio_net_config))
>>>+ if (offset + len <= sizeof(struct virtio_net_config))
>>> memcpy(buf, (u8 *)&ndev->config + offset, len);
>>> }
>>Actually first I am not sure we need these checks at all.
>>vhost_vdpa_config_validate already validates the values, right?
>
>
>I think they're working at different levels. There's no guarantee that
>vhost-vdpa is the driver for this vdpa device.
>
Maybe we can do these checks in the vdpa_get_config() helper and we can
also add a vdpa_set_config() to do the same.
Thanks,
Stefano
>
>>
>>Second, what will happen when we extend the struct and then
>>run new userspace on an old kernel? Looks like it will just
>>fail right? So what is the plan?
>
>
>In this case, get_config() should match the spec behaviour. That is to
>say the size of config space depends on the feature negotiated.
>
>Thanks
>
>
>> I think we should
>>allow a bigger size, and return the copied config size to userspace.
>>
>>
>>>--
>>>2.29.2
>
On Tue, Feb 09, 2021 at 07:43:02AM +0200, Eli Cohen wrote:
>On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>> It's legal to have 'offset + len' equal to
>> sizeof(struct virtio_net_config), since 'ndev->config' is a
>> 'struct virtio_net_config', so we can safely copy its content under
>> this condition.
>>
>> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
>> Cc: [email protected]
>> Signed-off-by: Stefano Garzarella <[email protected]>
>
>Acked-by: Eli Cohen <[email protected]>
>
>BTW, same error in vdpa_sim you may want to fix.
>
Commit 65b709586e22 ("vdpa_sim: add get_config callback in
vdpasim_dev_attr") unintentionally solved it.
Since it's a simulator, maybe we can avoid solving it in the stable
branches. Or does it matter?
Thanks,
Stefano
>> ---
>> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> index dc88559a8d49..10e9b09932eb 100644
>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
>> struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>> struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>>
>> - if (offset + len < sizeof(struct virtio_net_config))
>> + if (offset + len <= sizeof(struct virtio_net_config))
>> memcpy(buf, (u8 *)&ndev->config + offset, len);
>> }
>>
>> --
>> 2.29.2
>>
>
On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
>
> On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
> > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> > > It's legal to have 'offset + len' equal to
> > > sizeof(struct virtio_net_config), since 'ndev->config' is a
> > > 'struct virtio_net_config', so we can safely copy its content under
> > > this condition.
> > >
> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> > > Cc: [email protected]
> > > Signed-off-by: Stefano Garzarella <[email protected]>
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index dc88559a8d49..10e9b09932eb 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
> > > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> > > - if (offset + len < sizeof(struct virtio_net_config))
> > > + if (offset + len <= sizeof(struct virtio_net_config))
> > > memcpy(buf, (u8 *)&ndev->config + offset, len);
> > > }
> > Actually first I am not sure we need these checks at all.
> > vhost_vdpa_config_validate already validates the values, right?
>
>
> I think they're working at different levels. There's no guarantee that
> vhost-vdpa is the driver for this vdpa device.
In fact, get_config returns void, so userspace can easily get
trash if it passes incorrect parameters by mistake, there is
no way for userspace to find out whether that is the case :(
Any objections to returning the # of bytes copied, or -1
on error?
>
> >
> > Second, what will happen when we extend the struct and then
> > run new userspace on an old kernel? Looks like it will just
> > fail right? So what is the plan?
>
>
> In this case, get_config() should match the spec behaviour. That is to say
> the size of config space depends on the feature negotiated.
>
> Thanks
Yes but spec says config space can be bigger than specified by features:
Drivers MUST NOT limit structure size and device configuration space size. Instead, drivers SHOULD only
check that device configuration space is large enough to contain the fields necessary for device operation.
>
> > I think we should
> > allow a bigger size, and return the copied config size to userspace.
> >
> >
> > > --
> > > 2.29.2
On 2021/2/9 下午5:00, Stefano Garzarella wrote:
> On Tue, Feb 09, 2021 at 07:43:02AM +0200, Eli Cohen wrote:
>> On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>>> It's legal to have 'offset + len' equal to
>>> sizeof(struct virtio_net_config), since 'ndev->config' is a
>>> 'struct virtio_net_config', so we can safely copy its content under
>>> this condition.
>>>
>>> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
>>> devices")
>>> Cc: [email protected]
>>> Signed-off-by: Stefano Garzarella <[email protected]>
>>
>> Acked-by: Eli Cohen <[email protected]>
>>
>> BTW, same error in vdpa_sim you may want to fix.
>>
>
> Commit 65b709586e22 ("vdpa_sim: add get_config callback in
> vdpasim_dev_attr") unintentionally solved it.
>
> Since it's a simulator, maybe we can avoid solving it in the stable
> branches. Or does it matter?
I think not, since the module depends on RUNTIME_TESTING_MENU.
Thanks
>
> Thanks,
> Stefano
On Tue, Feb 09, 2021 at 04:31:23AM -0500, Michael S. Tsirkin wrote:
>On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
>>
>> On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
>> > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>> > > It's legal to have 'offset + len' equal to
>> > > sizeof(struct virtio_net_config), since 'ndev->config' is a
>> > > 'struct virtio_net_config', so we can safely copy its content under
>> > > this condition.
>> > >
>> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
>> > > Cc: [email protected]
>> > > Signed-off-by: Stefano Garzarella <[email protected]>
>> > > ---
>> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > index dc88559a8d49..10e9b09932eb 100644
>> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> > > @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device *vdev, unsigned int offset,
>> > > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>> > > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>> > > - if (offset + len < sizeof(struct virtio_net_config))
>> > > + if (offset + len <= sizeof(struct virtio_net_config))
>> > > memcpy(buf, (u8 *)&ndev->config + offset, len);
>> > > }
>> > Actually first I am not sure we need these checks at all.
>> > vhost_vdpa_config_validate already validates the values, right?
>>
>>
>> I think they're working at different levels. There's no guarantee that
>> vhost-vdpa is the driver for this vdpa device.
>
>In fact, get_config returns void, so userspace can easily get
>trash if it passes incorrect parameters by mistake, there is
>no way for userspace to find out whether that is the case :(
>
>Any objections to returning the # of bytes copied, or -1
>on error?
Make sense for me, but are we sure we don't break userspace if we return
the number of bytes instead of 0 on success?
I had a quick look at QEMU and it looks like we consider success if the
return value is >= 0, but I need to check further.
>
>>
>> >
>> > Second, what will happen when we extend the struct and then
>> > run new userspace on an old kernel? Looks like it will just
>> > fail right? So what is the plan?
>>
>>
>> In this case, get_config() should match the spec behaviour. That is to say
>> the size of config space depends on the feature negotiated.
>>
>> Thanks
>
>Yes but spec says config space can be bigger than specified by features:
>
> Drivers MUST NOT limit structure size and device configuration space size. Instead, drivers SHOULD only
> check that device configuration space is large enough to contain the fields necessary for device operation.
>
So IIUC in the driver we should copy as much as we can.
If you agree, I can send an RFC series and we can continue the
discussion on it, but I think we should queue this patch for stable
branches.
Thanks,
Stefano
On Wed, Feb 10, 2021 at 12:17:19PM +0800, Jason Wang wrote:
>
> On 2021/2/9 下午5:00, Stefano Garzarella wrote:
> > On Tue, Feb 09, 2021 at 07:43:02AM +0200, Eli Cohen wrote:
> > > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> > > > It's legal to have 'offset + len' equal to
> > > > sizeof(struct virtio_net_config), since 'ndev->config' is a
> > > > 'struct virtio_net_config', so we can safely copy its content under
> > > > this condition.
> > > >
> > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported
> > > > mlx5 devices")
> > > > Cc: [email protected]
> > > > Signed-off-by: Stefano Garzarella <[email protected]>
> > >
> > > Acked-by: Eli Cohen <[email protected]>
> > >
> > > BTW, same error in vdpa_sim you may want to fix.
> > >
> >
> > Commit 65b709586e22 ("vdpa_sim: add get_config callback in
> > vdpasim_dev_attr") unintentionally solved it.
> >
> > Since it's a simulator, maybe we can avoid solving it in the stable
> > branches. Or does it matter?
>
>
> I think not, since the module depends on RUNTIME_TESTING_MENU.
>
> Thanks
>
Well people use the simulator for development...
I'm not going to block this patch on it, but if someone
has the cycles to post a stable branch patch, that would be
great.
>
>
> >
> > Thanks,
> > Stefano
On Wed, Feb 10, 2021 at 07:12:31AM -0500, Michael S. Tsirkin wrote:
>On Wed, Feb 10, 2021 at 12:17:19PM +0800, Jason Wang wrote:
>>
>> On 2021/2/9 下午5:00, Stefano Garzarella wrote:
>> > On Tue, Feb 09, 2021 at 07:43:02AM +0200, Eli Cohen wrote:
>> > > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>> > > > It's legal to have 'offset + len' equal to
>> > > > sizeof(struct virtio_net_config), since 'ndev->config' is a
>> > > > 'struct virtio_net_config', so we can safely copy its content under
>> > > > this condition.
>> > > >
>> > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported
>> > > > mlx5 devices")
>> > > > Cc: [email protected]
>> > > > Signed-off-by: Stefano Garzarella <[email protected]>
>> > >
>> > > Acked-by: Eli Cohen <[email protected]>
>> > >
>> > > BTW, same error in vdpa_sim you may want to fix.
>> > >
>> >
>> > Commit 65b709586e22 ("vdpa_sim: add get_config callback in
>> > vdpasim_dev_attr") unintentionally solved it.
>> >
>> > Since it's a simulator, maybe we can avoid solving it in the stable
>> > branches. Or does it matter?
>>
>>
>> I think not, since the module depends on RUNTIME_TESTING_MENU.
>>
>> Thanks
>>
>
>Well people use the simulator for development...
>I'm not going to block this patch on it, but if someone
>has the cycles to post a stable branch patch, that would be
>great.
>
Okay, I'll do it.
Thanks,
Stefano
On 2021/2/10 下午6:08, Stefano Garzarella wrote:
> On Tue, Feb 09, 2021 at 04:31:23AM -0500, Michael S. Tsirkin wrote:
>> On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
>>>
>>> On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
>>> > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
>>> > > It's legal to have 'offset + len' equal to
>>> > > sizeof(struct virtio_net_config), since 'ndev->config' is a
>>> > > 'struct virtio_net_config', so we can safely copy its content under
>>> > > this condition.
>>> > >
>>> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported
>>> mlx5 devices")
>>> > > Cc: [email protected]
>>> > > Signed-off-by: Stefano Garzarella <[email protected]>
>>> > > ---
>>> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
>>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>>> > >
>>> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> > > index dc88559a8d49..10e9b09932eb 100644
>>> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>>> > > @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct
>>> vdpa_device *vdev, unsigned int offset,
>>> > > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>>> > > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>>> > > - if (offset + len < sizeof(struct virtio_net_config))
>>> > > + if (offset + len <= sizeof(struct virtio_net_config))
>>> > > memcpy(buf, (u8 *)&ndev->config + offset, len);
>>> > > }
>>> > Actually first I am not sure we need these checks at all.
>>> > vhost_vdpa_config_validate already validates the values, right?
>>>
>>>
>>> I think they're working at different levels. There's no guarantee that
>>> vhost-vdpa is the driver for this vdpa device.
>>
>> In fact, get_config returns void, so userspace can easily get
>> trash if it passes incorrect parameters by mistake, there is
>> no way for userspace to find out whether that is the case :(
>>
>> Any objections to returning the # of bytes copied, or -1
>> on error?
>
> Make sense for me, but are we sure we don't break userspace if we
> return the number of bytes instead of 0 on success?
>
> I had a quick look at QEMU and it looks like we consider success if
> the return value is >= 0, but I need to check further.
So I think in the vdpa bus level, we can return #bytes and in vhost uAPI
level, we can return error if the size is not expected otherwise zero?
Thanks
>
>>
>>>
>>> >
>>> > Second, what will happen when we extend the struct and then
>>> > run new userspace on an old kernel? Looks like it will just
>>> > fail right? So what is the plan?
>>>
>>>
>>> In this case, get_config() should match the spec behaviour. That is
>>> to say
>>> the size of config space depends on the feature negotiated.
>>>
>>> Thanks
>>
>> Yes but spec says config space can be bigger than specified by features:
>>
>> Drivers MUST NOT limit structure size and device configuration
>> space size. Instead, drivers SHOULD only
>> check that device configuration space is large enough to contain
>> the fields necessary for device operation.
>>
>
> So IIUC in the driver we should copy as much as we can.
>
> If you agree, I can send an RFC series and we can continue the
> discussion on it, but I think we should queue this patch for stable
> branches.
>
> Thanks,
> Stefano
>