On Fri, Nov 12, 2021 at 10:46:46AM +0300, Roman Kagan wrote: > On Thu, Nov 11, 2021 at 06:59:43PM +0100, Philippe Mathieu-Daudé wrote: > > On 11/11/21 16:33, Roman Kagan wrote: > > > Fix the (hypothetical) potential problem when the value parsed out of > > > the vhost module parameter in sysfs overflows the return value from > > > vhost_kernel_memslots_limit. > > > > > > Signed-off-by: Roman Kagan <rvka...@yandex-team.ru> > > > --- > > > hw/virtio/vhost-backend.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/hw/virtio/vhost-backend.c b/hw/virtio/vhost-backend.c > > > index b65f8f7e97..44f7dbb243 100644 > > > --- a/hw/virtio/vhost-backend.c > > > +++ b/hw/virtio/vhost-backend.c > > > @@ -58,7 +58,7 @@ static int vhost_kernel_memslots_limit(struct vhost_dev > > > *dev) > > > if > > > (g_file_get_contents("/sys/module/vhost/parameters/max_mem_regions", > > > &s, NULL, NULL)) { > > > uint64_t val = g_ascii_strtoull(s, NULL, 10); > > > > Would using qemu_strtou64() simplify this? > > I'm afraid not. None of the existing strtoXX converting functions has > the desired output range (0 < retval < INT_MAX), so the following > condition will remain necessary anyway; then it doesn't seem to matter > which particular parser is used to extract the value which is in the > range, so I left the one that was already there to reduce churn.
If qemu_strtou64() can't handle all values in (0 < retval < INT_MAX) isn't that a bug in qemu_strtou64 ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|