All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] xl: Return an error if an empty file is passed to cd-insert
Date: Mon, 13 May 2013 12:03:05 +0200	[thread overview]
Message-ID: <5190BA59.20203@citrix.com> (raw)
In-Reply-To: <1368438343.537.18.camel@zakaz.uk.xensource.com>

On 13/05/13 11:45, Ian Campbell wrote:
> On Mon, 2013-05-13 at 10:35 +0100, Roger Pau Monne wrote:
>> On 10/05/13 17:43, George Dunlap wrote:
>>> Two changes:
>>> * Stat the file before calling libxl_cdrom_insert()
>>> * Return an error if anything fails (including libxl_cdrom_insert)
>>>
>>> This is in part to work around the fact that the RAW disk type
>>> is used for things that aren't actually files; so we can't call
>>> stat in libxl_device.c:libxl__device_disk_set_backend() because
>>> it may be going over a remote protocol.
>>>
>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>> CC: Ian Campbell <ian.campbell@citrix.com>
>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>> ---
>>>  tools/libxl/xl_cmdimpl.c |   26 +++++++++++++++++++++-----
>>>  1 file changed, 21 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>>> index c1a969b..e8ce35b 100644
>>> --- a/tools/libxl/xl_cmdimpl.c
>>> +++ b/tools/libxl/xl_cmdimpl.c
>>> @@ -2505,25 +2505,42 @@ int main_memset(int argc, char **argv)
>>>      return 0;
>>>  }
>>>  
>>> -static void cd_insert(uint32_t domid, const char *virtdev, char *phys)
>>> +static int cd_insert(uint32_t domid, const char *virtdev, char *phys)
>>>  {
>>>      libxl_device_disk disk; /* we don't free disk's contents */
>>>      char *buf = NULL;
>>>      XLU_Config *config = 0;
>>> +    struct stat b;
>>> +    int rc = 0;
>>>  
>>>  
>>>      if (asprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
>>>                   virtdev, phys ? phys : "") < 0) {
>>>          fprintf(stderr, "out of memory\n");
>>> -        return;
>>> +        return 1;
>>
>> ERROR_NOMEM
> 
> xl seems pretty inconsistent in its use of libxl error codes, sometimes
> it uses +ERROR_FOO, other times -ERROR_FOO and other times it uses its
> own open coded numbers.
> 
> So I wouldn't say this is wrong as such but so long as the final xl exit
> code is 0 on success and non-zero otherwise I think it is up to George.

Yes I agree, xl is full of return 1, -1 and things like that, but anyway
I think it was worth mentioning.

>>
>>>      }
>>>  
>>>      parse_disk_config(&config, buf, &disk);
>>>  
>>> -    libxl_cdrom_insert(ctx, domid, &disk, NULL);
>>> +    /* ATM the existence of the backing file is not checked for qdisk
>>> +     * in libxl_cdrom_insert() because RAW is used for remote
>>> +     * protocols as well as plain files.  This will ideally be changed
>>> +     * for 4.4, but this work-around fixes the problem of "cd-insert"
>>> +     * returning success for non-existent files. */
>>> +    if (disk.format != LIBXL_DISK_FORMAT_EMPTY
>>> +        && stat(disk.pdev_path, &b)) {
>>> +        fprintf(stderr, "Cannot stat file: %s\n",
>>> +                disk.pdev_path);
>>
>> You are leaking buf here, I know xl is just about to exit,
> 
> I prefer to have xl clear up properly whenever possible. Not because I
> care particularly about xl (which isn't generally long lived) but
> because it makes it possible to use valgrind+xl to check for leaks in
> libxl, and I care about that because other toolstacks which use libxl
> can be long lived and therefore care about leaks. Having xl not contain
> false positive leaks helps here.
> 
> Ian.
> 

  reply	other threads:[~2013-05-13 10:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 15:43 [PATCH] xl: Return an error if an empty file is passed to cd-insert George Dunlap
2013-05-10 15:57 ` George Dunlap
2013-05-13  9:35 ` Roger Pau Monné
2013-05-13  9:45   ` Ian Campbell
2013-05-13 10:03     ` Roger Pau Monné [this message]
2013-05-13 10:31   ` George Dunlap
  -- strict thread matches above, loose matches on Subject: below --
2013-05-14 10:07 George Dunlap
2013-05-30  9:00 ` Ian Campbell
2013-05-30  9:28   ` George Dunlap

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=5190BA59.20203@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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.