On Thu, Aug 02, 2018 at 09:23:05PM +0200, Matthias Bolte wrote:
> 2018-08-02 18:16 GMT+02:00 John Ferlan :
> >
> >
> > On 08/02/2018 12:11 PM, Marcos Paulo de Souza wrote:
> >> On Thu, Aug 02, 2018 at 05:37:46PM +0200, Matthias Bolte wrote:
> >>> 2018-08-02 16:45 GMT+02:00 John Ferlan :
>
>
Instead of adding the same check for every drivers, execute the checks
in virAuthGetUsername and virAuthGetPassword. These funtions are called
when user is not set in the URI.
Signed-off-by: Marcos Paulo de Souza
---
src/util/virauth.c | 12
1 file changed, 12 insertions(+)
diff
Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed.
Signed-off-by: Marcos Paulo de Souza
---
src/esx/esx_driver.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index c2154799fa..15785858c6 100644
---
Since they are done inside virAuthGetPassword and virAuthGetUsername
when needed. Also, only auth is checked, but auth->cb, which that could
lead to a crash if the callback is NULL.
Signed-off-by: Marcos Paulo de Souza
---
src/xenapi/xenapi_driver.c | 6 --
1 file changed, 6 deletions(-)
On 08/02/2018 12:11 PM, Marcos Paulo de Souza wrote:
> On Thu, Aug 02, 2018 at 05:37:46PM +0200, Matthias Bolte wrote:
>> 2018-08-02 16:45 GMT+02:00 John Ferlan :
>>>
>>>
>>> On 08/02/2018 10:07 AM, Matthias Bolte wrote:
2018-08-02 15:20 GMT+02:00 John Ferlan :
>
>
> On
On Thu, Aug 02, 2018 at 05:37:46PM +0200, Matthias Bolte wrote:
> 2018-08-02 16:45 GMT+02:00 John Ferlan :
> >
> >
> > On 08/02/2018 10:07 AM, Matthias Bolte wrote:
> >> 2018-08-02 15:20 GMT+02:00 John Ferlan :
> >>>
> >>>
> >>> On 08/02/2018 05:04 AM, Matthias Bolte wrote:
> 2018-08-01 18:09
2018-08-02 16:45 GMT+02:00 John Ferlan :
>
>
> On 08/02/2018 10:07 AM, Matthias Bolte wrote:
>> 2018-08-02 15:20 GMT+02:00 John Ferlan :
>>>
>>>
>>> On 08/02/2018 05:04 AM, Matthias Bolte wrote:
2018-08-01 18:09 GMT+02:00 Marcos Paulo de Souza
:
> This is a new version from the last
When a domain is killed on the source host while it is being migrated
and libvirtd is waiting for the migration to finish (waiting for the
domain condition in qemuMigrationSrcWaitForCompletion), the run-time
state including priv->job.current may already be freed once
virDomainObjWait returns with
On 08/02/2018 10:07 AM, Matthias Bolte wrote:
> 2018-08-02 15:20 GMT+02:00 John Ferlan :
>>
>>
>> On 08/02/2018 05:04 AM, Matthias Bolte wrote:
>>> 2018-08-01 18:09 GMT+02:00 Marcos Paulo de Souza
>>> :
This is a new version from the last patchset sent yesterday, but now using
2018-08-02 15:20 GMT+02:00 John Ferlan :
>
>
> On 08/02/2018 05:04 AM, Matthias Bolte wrote:
>> 2018-08-01 18:09 GMT+02:00 Marcos Paulo de Souza
>> :
>>> This is a new version from the last patchset sent yesterday, but now using
>>> VIR_STRNDUP, instead of allocating memory manually.
>>>
>>>
On Sat, Jul 28, 2018 at 11:31:17PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On 08/02/2018 03:57 AM, Peter Krempa wrote:
> On Wed, Aug 01, 2018 at 17:44:56 -0400, John Ferlan wrote:
>> On 08/01/2018 04:44 PM, Laine Stump wrote:
>
> [...]
>
>>> At any rate, there is no perfect solution in sight for the current
>>> release, so the question is whether the new (bad)
On Sat, Jul 28, 2018 at 11:31:16PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On 08/02/2018 05:04 AM, Matthias Bolte wrote:
> 2018-08-01 18:09 GMT+02:00 Marcos Paulo de Souza :
>> This is a new version from the last patchset sent yesterday, but now using
>> VIR_STRNDUP, instead of allocating memory manually.
>>
>> First version:
>>
virRandomBits is implemented in terms of virRandomBytes. Although we
mock virRandomBytes to give a stable value, this is not sufficient to
make virRandomBits give a stable value. The result of virRandomBits will
vary depending on endianness. Thus we mock virRandomBits to return a
stable value
On Thursday, 2 August 2018 12:28:45 CEST Daniel P. Berrangé wrote:
> On Thu, Aug 02, 2018 at 10:17:32AM +0200, Bjoern Walk wrote:
> > Pino Toscano [2018-08-02, 10:02AM +0200]:
> > > I do not think this patch is correct: we are dealing with random bytes,
> > > so there is no "endianness" for them.
2018-08-01 18:09 GMT+02:00 Marcos Paulo de Souza :
> This is a new version from the last patchset sent yesterday, but now using
> VIR_STRNDUP, instead of allocating memory manually.
>
> First version:
> https://www.redhat.com/archives/libvir-list/2018-August/msg0.html
>
> Marcos Paulo de
On Thu, Aug 02, 2018 at 10:35:27AM +0200, Erik Skultety wrote:
> On Thu, Aug 02, 2018 at 01:06:39AM -0300, Julio Faracco wrote:
> > This commit fixes a segmentation fault caused by missing conditional to
> > check if libxl configuration was properly created by the test. If the
> > configuration
On Thu, Aug 02, 2018 at 01:06:39AM -0300, Julio Faracco wrote:
> This commit fixes a segmentation fault caused by missing conditional to
> check if libxl configuration was properly created by the test. If the
> configuration was not properly created, libxlDriverConfigNew() function
> will return
From: Clementine Hayat
Change the SetContext function to be able to take the session type in
argument.
Took the function findPoolSources of iscsi backend and wired it to my
function since the formatting is essentially the same.
Signed-off-by: Clementine Hayat
---
Pino Toscano [2018-08-02, 10:02AM +0200]:
> I do not think this patch is correct: we are dealing with random bytes,
> so there is no "endianness" for them.
Well, it's not incorrect either, isn't it? I agree that endianness
doesn't matter for random data, but in the same time, it doesn't hurt to
On Wed, Aug 01, 2018 at 17:44:56 -0400, John Ferlan wrote:
> On 08/01/2018 04:44 PM, Laine Stump wrote:
[...]
> > At any rate, there is no perfect solution in sight for the current
> > release, so the question is whether the new (bad) behavior is better or
> > worse than the old (also bad)
Make the generation of random bits in virRandomBits independent of the
endianness of the running architecture.
This also solves problems with the mocked random byte generation on
big-endian machines.
Suggested-by: Daniel P. Berrangé
Signed-off-by: Bjoern Walk
---
This goes on top of Michal's
On Thu, 2 Aug 2018 09:33:48 +0200
Cornelia Huck wrote:
> On Thu, 2 Aug 2018 09:15:24 +0200
> Cornelia Huck wrote:
>
> > On Thu, 2 Aug 2018 09:34:37 +0800
> > Fam Zheng wrote:
> >
> > > On Wed, Aug 1, 2018 at 9:18 PM Cornelia Huck wrote:
> > >
> > > >
> > > > On Wed, 1 Aug 2018
On Thu, 2 Aug 2018 09:15:24 +0200
Cornelia Huck wrote:
> On Thu, 2 Aug 2018 09:34:37 +0800
> Fam Zheng wrote:
>
> > On Wed, Aug 1, 2018 at 9:18 PM Cornelia Huck wrote:
> > >
> > > On Wed, 1 Aug 2018 15:11:23 +0200
> > > Cornelia Huck wrote:
> > >
> > > > On Wed, 1 Aug 2018 14:54:51
On 08/01/2018 04:50 PM, Eric Blake wrote:
> On 08/01/2018 07:16 AM, Daniel P. Berrangé wrote:
>> On Wed, Aug 01, 2018 at 01:44:32PM +0200, Michal Privoznik wrote:
>>> The function is supposed to return up to 64bit long integer. In
>>> order to do that it calls virRandomBytes() to fill the integer
On 08/01/2018 04:48 PM, Eric Blake wrote:
> On 08/01/2018 06:44 AM, Michal Privoznik wrote:
>> In virStorageBackendCreateIfaceIQN() the virRandomBits() is
>> called in order to use random bits to generate random name for
>> new interface. However, virAsprintf() is expecting 32 bits and we
>> are
On Thu, 2 Aug 2018 09:34:37 +0800
Fam Zheng wrote:
> On Wed, Aug 1, 2018 at 9:18 PM Cornelia Huck wrote:
> >
> > On Wed, 1 Aug 2018 15:11:23 +0200
> > Cornelia Huck wrote:
> >
> > > On Wed, 1 Aug 2018 14:54:51 +0200
> > > Cornelia Huck wrote:
> > >
> > > > On Wed, 1 Aug 2018 18:21:27
Eric Blake [2018-08-01, 09:51AM -0500]:
> On 08/01/2018 07:57 AM, Bjoern Walk wrote:
> > And here's the fix for the viriscsitest on big-endian machine like
> > Daniel suggested.
>
> > From d59b254294a90c5a9ca0fb6ad29465cd0950bb61 Mon Sep 17 00:00:00 2001
> > From: Bjoern Walk
> > Date: Wed, 1
29 matches
Mail list logo
