search for: err0

...en/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -176,8 +176,10 @@ int cpufreq_add_cpu(unsigned int cpu) if (!domexist || hw_all) { policy = xzalloc(struct cpufreq_policy); - if (!policy) + if (!policy) { ret = -ENOMEM; + goto err0; + } policy->cpu = cpu; per_cpu(cpufreq_cpu_policy, cpu) = policy; @@ -186,7 +188,7 @@ int cpufreq_add_cpu(unsigned int cpu) if (ret) { xfree(policy); per_cpu(cpufreq_cpu_policy, cpu) = NULL; - return ret; + goto...

...stcpu = cpumask_first(cpufreq_dom->map); if ((perf->domain_info.coord_type != processor_pminfo[firstcpu]->perf.domain_info.coord_type) || (perf->domain_info.num_processors != @@ -181,11 +186,18 @@ int cpufreq_add_cpu(unsigned int cpu) goto err0; } + if (!zalloc_cpumask_var(&policy->cpus)) { + xfree(policy); + ret = -ENOMEM; + goto err0; + } + policy->cpu = cpu; per_cpu(cpufreq_cpu_policy, cpu) = policy; ret = cpufreq_driver->init(policy);...

I believe this roughly implements Nir's proposal here: https://www.redhat.com/archives/libguestfs/2020-August/msg00028.html Unfortunately it doesn't work for me. It actually slows things down quite a lot, for reasons I don't understand. Note the adjustment of the pool-max parameter and how it affects the total time. The results are quite reproducible. $ ./nbdkit -r -U - vddk

...have to reserve this vector to ensure that it is not + * reallocated, as that would make the pointer returned by + * get_vddk_handle in another thread invalid. + */ + if (vddk_handles_reserve (&h->vddk_handles, pool_max) == -1) { + nbdkit_error ("realloc: %m"); + goto err0; + } + h->params = allocate_connect_params (); if (h->params == NULL) { nbdkit_error ("allocate VixDiskLibConnectParams: %m"); @@ -589,49 +625,120 @@ vddk_open (int readonly) goto err1; } - flags = 0; + h->flags = 0; if (readonly) - flags |= VIXDISKL...

...o ensure that it is not > + * reallocated, as that would make the pointer returned by > + * get_vddk_handle in another thread invalid. > + */ > + if (vddk_handles_reserve (&h->vddk_handles, pool_max) == -1) { > + nbdkit_error ("realloc: %m"); > + goto err0; > + } > + > h->params = allocate_connect_params (); > if (h->params == NULL) { > nbdkit_error ("allocate VixDiskLibConnectParams: %m"); > @@ -589,49 +625,120 @@ vddk_open (int readonly) > goto err1; > } > > - flags = 0; > + h-&...

...uot;nbdkit_io_encode: %m"); + return -1; + } + + err = ext2fs_open (name, fs_flags, 0, 0, nbdkit_io_manager, &h->fs); if (err != 0) { - nbdkit_error ("%s: open: %s", disk, error_message (err)); + nbdkit_error ("open: %s", error_message (err)); goto err0; } @@ -158,7 +181,7 @@ ext2_open (int readonly) err = ext2fs_namei (h->fs, EXT2_ROOT_INO, EXT2_ROOT_INO, &file[1], &h->ino); if (err != 0) { - nbdkit_error ("%s: %s: namei: %s", disk, file, error_message (err)); + nbdkit_error...

...%s", fname) < 0) { + nbdkit_error ("asprintf: %m"); + return -1; + } + fname = absname; + } + err = ext2fs_open (name, fs_flags, 0, 0, nbdkit_io_manager, &h->fs); if (err != 0) { nbdkit_error ("open: %s", error_message (err)); goto err0; } - if (strcmp (file, "/") == 0) + if (strcmp (fname, "/") == 0) /* probably gonna fail, but we'll catch it later */ h->ino = EXT2_ROOT_INO; else { err = ext2fs_namei (h->fs, EXT2_ROOT_INO, EXT2_ROOT_INO, - &file[1],...

There is a small test provided. I tested this a lot more locally and it seems pretty robust. Rich.

We had a query yesterday about the VDDK plugin and making it actually obey the weird "Multithreading Considerations" rules in the VDDK documentation (https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf) This patch is my attempt to implement this. The idea is that the

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Please review and comments. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Please review and comments. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was already merged to linux ia64 test branch. This patch is for linux ia64 test branch. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor.

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was already merged to linux ia64 test branch. This patch is for linux ia64 test branch. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor.

Hi. This patchset is ia64/xen domU patch take 8 which was updated following Tony's review. (Thank you very much, Tony.) This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset is for linux ia64 test branch and depends on some patches for xen common part I'll send separately. To compile, the changesets in x86/xen

Hi. This patchset is ia64/xen domU patch take 8 which was updated following Tony's review. (Thank you very much, Tony.) This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset is for linux ia64 test branch and depends on some patches for xen common part I'll send separately. To compile, the changesets in x86/xen