Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-02 Thread Eric Blake

On 03/01/2018 10:20 AM, Alex Williamson wrote:

On Thu,  1 Mar 2018 10:08:06 +0300
Julia Suvorova via Qemu-devel  wrote:


basename(3) and dirname(3) modify their argument and may return
pointers to statically allocated memory which may be overwritten by
subsequent calls.
g_path_get_basename and g_path_get_dirname have no such issues, and
therefore more preferable.


I think it's quite a bit arguable whether it's preferable, afaict there
are no bugs fixed here.  The basic functions are being used correctly
and are more conservative of memory usage than the glib variants.  In
several cases below the basic functions seem far more efficient and we
don't need to worry about freeing unnecessarily allocated memory, the
diffstat seems to attest to this.  Is the inefficiency and possibility
of leaking unintentionally allocated memory a statistical improvement
over the claimed perils of these absolutely standard and well known
functions?


The standard functions may be well-known, but as currently standardized 
are not very reliably useful in a multi-threaded program.  However, the 
standard WILL be improved in the future to require a saner standardized 
implementation (the proposed changes to the standard remove the ability 
for basename()/dirname() to return NULL, remove the allowance for 
non-thread-safe returns, and document more fully that the returned 
pointer will be back to the input string in all but a few corner cases 
which return const char *):


http://austingroupbugs.net/view.php?id=1064



I know mine is a losing battle against glib, but the changelog might as
well just say "Succumb to glib" because I fail to see that there's
actually an improvement here.  If Paolo wants to take this,


One thing that the glib functions can do that the standardized version 
cannot do is handle drive letters on DOS-like systems (doesn't affect 
our builds on Linux or BSD, but may matter to mingw builds).  But you 
are right that the glib functions are more malloc-heavy than the (fixed) 
standardized functions, so it becomes a trade-off of how likely the libc 
functions are to comply with the tighter future standard version (that 
is actually somewhat useful) vs. the current standard version (that is a 
piece of trash because it has too many loopholes).


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-02 Thread Paolo Bonzini
On 01/03/2018 17:20, Alex Williamson wrote:
>> basename(3) and dirname(3) modify their argument and may return
>> pointers to statically allocated memory which may be overwritten by
>> subsequent calls.
>> g_path_get_basename and g_path_get_dirname have no such issues, and
>> therefore more preferable.
>
> I think it's quite a bit arguable whether it's preferable, afaict there
> are no bugs fixed here.  The basic functions are being used correctly
> and are more conservative of memory usage than the glib variants.  In
> several cases below the basic functions seem far more efficient and we
> don't need to worry about freeing unnecessarily allocated memory, the
> diffstat seems to attest to this.  Is the inefficiency and possibility
> of leaking unintentionally allocated memory a statistical improvement
> over the claimed perils of these absolutely standard and well known
> functions?
> 
> I know mine is a losing battle against glib, but the changelog might as
> well just say "Succumb to glib" because I fail to see that there's
> actually an improvement here.  If Paolo wants to take this,
> 
> Acked-by: Alex Williamson 

Fair enough, I'll apply only the obvious cases like g_strdup(basename()).

Paolo



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Alex Williamson
On Thu,  1 Mar 2018 10:08:06 +0300
Julia Suvorova via Qemu-devel  wrote:

> basename(3) and dirname(3) modify their argument and may return
> pointers to statically allocated memory which may be overwritten by
> subsequent calls.
> g_path_get_basename and g_path_get_dirname have no such issues, and
> therefore more preferable.

I think it's quite a bit arguable whether it's preferable, afaict there
are no bugs fixed here.  The basic functions are being used correctly
and are more conservative of memory usage than the glib variants.  In
several cases below the basic functions seem far more efficient and we
don't need to worry about freeing unnecessarily allocated memory, the
diffstat seems to attest to this.  Is the inefficiency and possibility
of leaking unintentionally allocated memory a statistical improvement
over the claimed perils of these absolutely standard and well known
functions?

I know mine is a losing battle against glib, but the changelog might as
well just say "Succumb to glib" because I fail to see that there's
actually an improvement here.  If Paolo wants to take this,

Acked-by: Alex Williamson 

Thanks,
Alex
 
> Signed-off-by: Julia Suvorova 
> ---
>  fsdev/virtfs-proxy-helper.c |  6 +-
>  hw/s390x/s390-ccw.c | 17 +++--
>  hw/vfio/ccw.c   |  7 +--
>  hw/vfio/pci.c   |  6 --
>  hw/vfio/platform.c  |  6 --
>  qemu-io.c   |  8 +++-
>  qemu-nbd.c  |  5 -
>  qga/commands-posix.c|  4 ++--
>  8 files changed, 42 insertions(+), 17 deletions(-)
> 
> diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
> index 8e48500..da3452f 100644
> --- a/fsdev/virtfs-proxy-helper.c
> +++ b/fsdev/virtfs-proxy-helper.c
> @@ -787,6 +787,8 @@ error:
>  
>  static void usage(char *prog)
>  {
> +char *base_filename = g_path_get_basename(prog);
> +
>  fprintf(stderr, "usage: %s\n"
>  " -p|--path  9p path to export\n"
>  " {-f|--fd } socket file descriptor to be 
> used\n"
> @@ -795,7 +797,9 @@ static void usage(char *prog)
>  " access to this socket\n"
>  " \tNote: -s & -f can not be used together\n"
>  " [-n|--nodaemon] Run as a normal program\n",
> -basename(prog));
> +base_filename);
> +
> +g_free(base_filename);
>  }
>  
>  static int process_reply(int sock, int type,
> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c
> index 7fc1c60..460dbab 100644
> --- a/hw/s390x/s390-ccw.c
> +++ b/hw/s390x/s390-ccw.c
> @@ -34,7 +34,7 @@ static void s390_ccw_get_dev_info(S390CCWDevice *cdev,
>Error **errp)
>  {
>  unsigned int cssid, ssid, devid;
> -char dev_path[PATH_MAX] = {0}, *tmp;
> +char dev_path[PATH_MAX] = {0}, *dir_name, *dir_path;
>  
>  if (!sysfsdev) {
>  error_setg(errp, "No host device provided");
> @@ -48,18 +48,23 @@ static void s390_ccw_get_dev_info(S390CCWDevice *cdev,
>  return;
>  }
>  
> -cdev->mdevid = g_strdup(basename(dev_path));
> +cdev->mdevid = g_path_get_basename(dev_path);
>  
> -tmp = basename(dirname(dev_path));
> -if (sscanf(tmp, "%2x.%1x.%4x", , , ) != 3) {
> -error_setg_errno(errp, errno, "Failed to read %s", tmp);
> -return;
> +dir_path = g_path_get_dirname(dev_path);
> +dir_name = g_path_get_basename(dir_path);
> +if (sscanf(dir_name, "%2x.%1x.%4x", , , ) != 3) {
> +error_setg_errno(errp, errno, "Failed to read %s", dir_name);
> +goto out;
>  }
>  
>  cdev->hostid.cssid = cssid;
>  cdev->hostid.ssid = ssid;
>  cdev->hostid.devid = devid;
>  cdev->hostid.valid = true;
> +
> +out:
> +g_free(dir_path);
> +g_free(dir_name);
>  }
>  
>  static void s390_ccw_realize(S390CCWDevice *cdev, char *sysfsdev, Error 
> **errp)
> diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> index 16713f2..c0566a9 100644
> --- a/hw/vfio/ccw.c
> +++ b/hw/vfio/ccw.c
> @@ -300,7 +300,7 @@ static void vfio_put_device(VFIOCCWDevice *vcdev)
>  
>  static VFIOGroup *vfio_ccw_get_group(S390CCWDevice *cdev, Error **errp)
>  {
> -char *tmp, group_path[PATH_MAX];
> +char *tmp, *group_name, group_path[PATH_MAX];
>  ssize_t len;
>  int groupid;
>  
> @@ -317,10 +317,13 @@ static VFIOGroup *vfio_ccw_get_group(S390CCWDevice 
> *cdev, Error **errp)
>  
>  group_path[len] = 0;
>  
> -if (sscanf(basename(group_path), "%d", ) != 1) {
> +group_name = g_path_get_basename(group_path);
> +if (sscanf(group_name, "%d", ) != 1) {
>  error_setg(errp, "vfio: failed to read %s", group_path);
> +g_free(group_name);
>  return NULL;
>  }
> +g_free(group_name);
>  
>  return vfio_get_group(groupid, _space_memory, errp);
>  }
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 033cc8d..ba03136 100644
> --- a/hw/vfio/pci.c
> +++ 

Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Julia Suvorova via Qemu-devel


On 01.03.2018 14:21, Paolo Bonzini wrote:
> On 01/03/2018 11:59, Cornelia Huck wrote:

 Signed-off-by: Julia Suvorova   
>>> What about adding a warning for basename()/dirname() usage in
>>> scripts/checkpatch.pl ?
>> +1 to that.
>>
> 
> Good idea indeed.  Julia, would you like to send a second patch that
> adds the warning?
>  

Ok, sure.

> There are already some examples (__FUNCTION__, strto*, signal, etc.)
> that you can take inspiration from.
> 

Thanks for the tips.



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Julia Suvorova via Qemu-devel


On 01.03.2018 13:59, Cornelia Huck wrote:
> On Thu, 1 Mar 2018 10:47:42 +0100
> Marc-André Lureau  wrote:
> 
>> Hi
>>
>> On Thu, Mar 1, 2018 at 8:08 AM, Julia Suvorova via Qemu-devel
>>  wrote:
>>> basename(3) and dirname(3) modify their argument and may return
>>> pointers to statically allocated memory which may be overwritten by
>>> subsequent calls.
>>> g_path_get_basename and g_path_get_dirname have no such issues, and
>>> therefore more preferable.
>>>
>>> Signed-off-by: Julia Suvorova   
>>
>> What about adding a warning for basename()/dirname() usage in
>> scripts/checkpatch.pl ?
> 
> +1 to that.
> 

Ok. I'll prepare a separate patch for that.
Thanks for the review.

>>
>> Reviewed-by: Marc-André Lureau 
> 
> Reviewed-by: Cornelia Huck 
> 



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Paolo Bonzini
On 01/03/2018 11:59, Cornelia Huck wrote:
>>>
>>> Signed-off-by: Julia Suvorova   
>> What about adding a warning for basename()/dirname() usage in
>> scripts/checkpatch.pl ?
> +1 to that.
> 

Good idea indeed.  Julia, would you like to send a second patch that
adds the warning?

There are already some examples (__FUNCTION__, strto*, signal, etc.)
that you can take inspiration from.

Paolo



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Paolo Bonzini
On 01/03/2018 08:08, Julia Suvorova wrote:
> +static void free_progname(void)
> +{
> +g_free(progname);
> +}
> +
>  static void GCC_FMT_ATTR(2, 3) readline_printf_func(void *opaque,
>  const char *fmt, ...)
>  {
> @@ -504,7 +509,8 @@ int main(int argc, char **argv)
>  #endif
>  
>  module_call_init(MODULE_INIT_TRACE);
> -progname = basename(argv[0]);
> +progname = g_path_get_basename(argv[0]);
> +atexit(free_progname);

This atexit is not needed; memory is always freed on exit.  But, it's
good that you thought about it!

I can queue this patch for merging once I get an ack from Alex
Williamson (VFIO).

Thanks,

Paolo



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Cornelia Huck
On Thu, 1 Mar 2018 10:47:42 +0100
Marc-André Lureau  wrote:

> Hi
> 
> On Thu, Mar 1, 2018 at 8:08 AM, Julia Suvorova via Qemu-devel
>  wrote:
> > basename(3) and dirname(3) modify their argument and may return
> > pointers to statically allocated memory which may be overwritten by
> > subsequent calls.
> > g_path_get_basename and g_path_get_dirname have no such issues, and
> > therefore more preferable.
> >
> > Signed-off-by: Julia Suvorova   
> 
> What about adding a warning for basename()/dirname() usage in
> scripts/checkpatch.pl ?

+1 to that.

> 
> Reviewed-by: Marc-André Lureau 

Reviewed-by: Cornelia Huck 



Re: [Qemu-devel] [PATCH] use g_path_get_basename instead of basename

2018-03-01 Thread Marc-André Lureau
Hi

On Thu, Mar 1, 2018 at 8:08 AM, Julia Suvorova via Qemu-devel
 wrote:
> basename(3) and dirname(3) modify their argument and may return
> pointers to statically allocated memory which may be overwritten by
> subsequent calls.
> g_path_get_basename and g_path_get_dirname have no such issues, and
> therefore more preferable.
>
> Signed-off-by: Julia Suvorova 

What about adding a warning for basename()/dirname() usage in
scripts/checkpatch.pl ?

Reviewed-by: Marc-André Lureau 


> ---
>  fsdev/virtfs-proxy-helper.c |  6 +-
>  hw/s390x/s390-ccw.c | 17 +++--
>  hw/vfio/ccw.c   |  7 +--
>  hw/vfio/pci.c   |  6 --
>  hw/vfio/platform.c  |  6 --
>  qemu-io.c   |  8 +++-
>  qemu-nbd.c  |  5 -
>  qga/commands-posix.c|  4 ++--
>  8 files changed, 42 insertions(+), 17 deletions(-)
>
> diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
> index 8e48500..da3452f 100644
> --- a/fsdev/virtfs-proxy-helper.c
> +++ b/fsdev/virtfs-proxy-helper.c
> @@ -787,6 +787,8 @@ error:
>
>  static void usage(char *prog)
>  {
> +char *base_filename = g_path_get_basename(prog);
> +
>  fprintf(stderr, "usage: %s\n"
>  " -p|--path  9p path to export\n"
>  " {-f|--fd } socket file descriptor to be 
> used\n"
> @@ -795,7 +797,9 @@ static void usage(char *prog)
>  " access to this socket\n"
>  " \tNote: -s & -f can not be used together\n"
>  " [-n|--nodaemon] Run as a normal program\n",
> -basename(prog));
> +base_filename);
> +
> +g_free(base_filename);
>  }
>
>  static int process_reply(int sock, int type,
> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c
> index 7fc1c60..460dbab 100644
> --- a/hw/s390x/s390-ccw.c
> +++ b/hw/s390x/s390-ccw.c
> @@ -34,7 +34,7 @@ static void s390_ccw_get_dev_info(S390CCWDevice *cdev,
>Error **errp)
>  {
>  unsigned int cssid, ssid, devid;
> -char dev_path[PATH_MAX] = {0}, *tmp;
> +char dev_path[PATH_MAX] = {0}, *dir_name, *dir_path;
>
>  if (!sysfsdev) {
>  error_setg(errp, "No host device provided");
> @@ -48,18 +48,23 @@ static void s390_ccw_get_dev_info(S390CCWDevice *cdev,
>  return;
>  }
>
> -cdev->mdevid = g_strdup(basename(dev_path));
> +cdev->mdevid = g_path_get_basename(dev_path);
>
> -tmp = basename(dirname(dev_path));
> -if (sscanf(tmp, "%2x.%1x.%4x", , , ) != 3) {
> -error_setg_errno(errp, errno, "Failed to read %s", tmp);
> -return;
> +dir_path = g_path_get_dirname(dev_path);
> +dir_name = g_path_get_basename(dir_path);
> +if (sscanf(dir_name, "%2x.%1x.%4x", , , ) != 3) {
> +error_setg_errno(errp, errno, "Failed to read %s", dir_name);
> +goto out;
>  }
>
>  cdev->hostid.cssid = cssid;
>  cdev->hostid.ssid = ssid;
>  cdev->hostid.devid = devid;
>  cdev->hostid.valid = true;
> +
> +out:
> +g_free(dir_path);
> +g_free(dir_name);
>  }
>
>  static void s390_ccw_realize(S390CCWDevice *cdev, char *sysfsdev, Error 
> **errp)
> diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> index 16713f2..c0566a9 100644
> --- a/hw/vfio/ccw.c
> +++ b/hw/vfio/ccw.c
> @@ -300,7 +300,7 @@ static void vfio_put_device(VFIOCCWDevice *vcdev)
>
>  static VFIOGroup *vfio_ccw_get_group(S390CCWDevice *cdev, Error **errp)
>  {
> -char *tmp, group_path[PATH_MAX];
> +char *tmp, *group_name, group_path[PATH_MAX];
>  ssize_t len;
>  int groupid;
>
> @@ -317,10 +317,13 @@ static VFIOGroup *vfio_ccw_get_group(S390CCWDevice 
> *cdev, Error **errp)
>
>  group_path[len] = 0;
>
> -if (sscanf(basename(group_path), "%d", ) != 1) {
> +group_name = g_path_get_basename(group_path);
> +if (sscanf(group_name, "%d", ) != 1) {
>  error_setg(errp, "vfio: failed to read %s", group_path);
> +g_free(group_name);
>  return NULL;
>  }
> +g_free(group_name);
>
>  return vfio_get_group(groupid, _space_memory, errp);
>  }
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 033cc8d..ba03136 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2807,7 +2807,7 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>  return;
>  }
>
> -vdev->vbasedev.name = g_strdup(basename(vdev->vbasedev.sysfsdev));
> +vdev->vbasedev.name = g_path_get_basename(vdev->vbasedev.sysfsdev);
>  vdev->vbasedev.ops = _pci_ops;
>  vdev->vbasedev.type = VFIO_DEVICE_TYPE_PCI;
>  vdev->vbasedev.dev = >pdev.qdev;
> @@ -2824,11 +2824,13 @@ static void vfio_realize(PCIDevice *pdev, Error 
> **errp)
>
>  group_path[len] = 0;
>
> -group_name = basename(group_path);
> +group_name = g_path_get_basename(group_path);
>  if (sscanf(group_name, "%d", ) != 1) {
>  error_setg_errno(errp, errno, "failed to read %s",