search for: nr_extents

....h" +#include "vector.h" #include "internal.h" @@ -51,9 +52,11 @@ */ #define MAX_EXTENTS (1 * 1024 * 1024) +/* Appendable list of extents. */ +DEFINE_VECTOR_TYPE(extents, struct nbdkit_extent); + struct nbdkit_extents { - struct nbdkit_extent *extents; - size_t nr_extents, allocated; + extents extents; uint64_t start, end; /* end is one byte beyond the end of the range */ @@ -92,8 +95,7 @@ nbdkit_extents_new (uint64_t start, uint64_t end) nbdkit_error ("nbdkit_extents_new: malloc: %m"); return NULL; } - r->extents = NULL; - r->...

...4,6 +44,7 @@ #include "cleanup.h" #include "minmax.h" +#include "vector.h" #define HOLE (NBDKIT_EXTENT_HOLE|NBDKIT_EXTENT_ZERO) @@ -56,31 +57,13 @@ struct extent { uint64_t offset, length; uint32_t type; }; -static struct extent *extents; -static size_t nr_extents, allocated; - -/* Insert an extent before i. If i = nr_extents, inserts at the end. */ -static void -insert_extent (size_t i, struct extent new_extent) -{ - if (nr_extents >= allocated) { - allocated = allocated == 0 ? 1 : allocated * 2; - extents = realloc (extents, (sizeof (struct exte...

...<EOPNOTSUPP> (while plugins have automatic fallback to C<.pwrite>, filters do not). +=head2 C<.extents> + + int (*extents) (struct nbdkit_next_ops *next_ops, void *nxdata, + void *handle, uint32_t count, uint64_t offset, uint32_t flags, + size_t *nr_extents, struct nbdkit_extent **extents, + int *err); + +This intercepts the plugin C<.extents> method and can be used to +modify extent requests. + +This function will not be called if C<.can_extents> returned false; in +turn, the filter should not call C<next_ops-E<gt&gt...

--- plugins/vddk/vddk.c | 41 +++++++++++++++++++++++++---------------- TODO | 1 - 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index 87c0d146..d1a3015f 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -51,6 +51,7 @@ #include "isaligned.h" #include "minmax.h" #include

This tentative commit implements extents/can_extents, roughly as discussed in the previous thread here: https://www.redhat.com/archives/libguestfs/2019-March/msg00017.html I can't say that I'm a big fan of having the plugin allocate an extents array. There are no other plugin callbacks currently where we require the plugin to allocate complex data structures (or indeed do any allocation

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

...uct backend *b, struct connection *conn, > count, offset, flags, err); > } > >+static int >+filter_extents (struct backend *b, struct connection *conn, >+ uint32_t count, uint64_t offset, uint32_t flags, >+ size_t *nr_extents, struct nbdkit_extent **extents, >+ int *err) >+{ >+ struct backend_filter *f = container_of (b, struct backend_filter, backend); >+ void *handle = connection_get_handle (conn, f->backend.i); >+ struct b_conn nxdata = { .b = f->backend.next, .conn = conn }; &g...

...;eblake@redhat.com> --- server/extents.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/server/extents.c b/server/extents.c index c4224916..0ebd77b1 100644 --- a/server/extents.c +++ b/server/extents.c @@ -45,6 +45,12 @@ #include "internal.h" +/* Cap nr_extents to avoid sending over-large replies to the client, + * and to avoid a plugin with frequent alternations consuming too much + * memory. + */ +#define MAX_EXTENTS (1 * 1024 * 1024) + struct nbdkit_extents { struct nbdkit_extent *extents; size_t nr_extents, allocated; @@ -163,8 +169,8 @@ nbdkit...

...e can't check for API usage errors. Nice comment... > + */ > + if (offset >= exts->end) > + return 0; Is returning 0 always right, or should we also check whether the user tried to pass in offset > end as their very first nbdkit_extents_add (where we know that because nr_extents is 0 that it is an API usage error). > + > + /* Shorten extents that overlap the end of the range. */ > + if (offset + length >= exts->end) { > + overlap = offset + length - exts->end; > + length -= overlap; > + } > + > + /* If there are existing extents,...

...tions. Instead, the (loop invariant) check added for addressing XSA-31 can be moved here. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -99,7 +99,8 @@ static void populate_physmap(struct memo a->nr_extents-1) ) return; - if ( !multipage_allocation_permitted(current->domain, a->extent_order) ) + if ( a->memflags & MEMF_populate_on_demand ? a->extent_order > MAX_ORDER : + !multipage_allocation_permitted(current->domain, a->extent_order) ) retur...

...plugins with lots of extents. + * + * Invariants: + * - extents are stored in ascending order + * - extents must not overlap + * - adjacent extents must not have the same type + * + * Gaps are treated as type 0 (allocated data). + */ +struct nbdkit_extents_map { + struct extent *extents; + size_t nr_extents, allocated; +}; + +struct extent { + uint64_t offset; + uint64_t length; + uint32_t type; +}; + +struct nbdkit_extents_map * +nbdkit_extents_new (void) +{ + struct nbdkit_extents_map *r; + + r = malloc (sizeof *r); + if (r == NULL) { + nbdkit_error ("nbdkit_extents_new: malloc: %m&quo...

...nclude <stdint.h> +#include <stdbool.h> +#include <string.h> +#include <inttypes.h> +#include <errno.h> +#include <assert.h> + +#include "minmax.h" + +#include "internal.h" + +struct nbdkit_extents { + struct nbdkit_extent *extents; + size_t nr_extents, allocated; + uint64_t start; +}; + +struct nbdkit_extents * +nbdkit_extents_new (uint64_t start) +{ + struct nbdkit_extents *r; + + if (start >= INT64_MAX) { + nbdkit_error ("nbdkit_extents_new: start (%" PRIu64 ") > INT64_MAX", + start); + errno...

...nclude <stdint.h> +#include <stdbool.h> +#include <string.h> +#include <inttypes.h> +#include <errno.h> +#include <assert.h> + +#include "minmax.h" + +#include "internal.h" + +struct nbdkit_extents { + struct nbdkit_extent *extents; + size_t nr_extents, allocated; + uint64_t start, end; /* end is one byte beyond the end of the range */ +}; + +struct nbdkit_extents * +nbdkit_extents_new (uint64_t start, uint64_t end) +{ + struct nbdkit_extents *r; + + if (start >= INT64_MAX || end >= INT64_MAX) { + nbdkit_error ("nbdkit_extents_ne...

Hi Jeremy. Here are the 3 patches for ia64/xen support. The first one is just to move manage.c under drivers/xen. This is trivial. The second and third ones are for compilation fix on ia64. You may want to postpone those 2 patches to make your merge task easy as you said before. thanks, Diffstat arch/x86/xen/Makefile | 2 +- drivers/xen/Makefile | 2 +-

Hi Jeremy. Here are the 3 patches for ia64/xen support. The first one is just to move manage.c under drivers/xen. This is trivial. The second and third ones are for compilation fix on ia64. You may want to postpone those 2 patches to make your merge task easy as you said before. thanks, Diffstat arch/x86/xen/Makefile | 2 +- drivers/xen/Makefile | 2 +-

...cmd, uint16_t flags, > + uint32_t count, uint64_t offset, > + struct nbdkit_extents *extents) > +{ > + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&conn->write_lock); > + struct structured_reply reply; > + size_t nr_extents = nbdkit_extents_size (extents); > + uint32_t context_id; > + size_t i; > + int r; > + > + assert (cmd == NBD_CMD_BLOCK_STATUS); > + Worth asserting conn->meta_context_base_allocation? > + > + /* Send each block descriptor. */ > + for (i = 0; i < nr_extents...

...truct nbdkit_extents *extents, uint16_t flags, uint32_t count, uint64_t offset, @@ -451,13 +451,14 @@ extents_to_block_descriptors (struct nbdkit_extents *extents, const bool req_one = flags & NBD_CMD_FLAG_REQ_ONE; const size_t nr_extents = nbdkit_extents_count (extents); size_t i; - struct block_descriptor *blocks; + struct nbd_block_descriptor *blocks; /* This is checked in server/plugins.c. */ assert (nr_extents >= 1); /* We may send fewer than nr_extents blocks, but never more. */ - blocks = calloc (req_one...

...clude <stdlib.h> +#include <stdint.h> +#include <stdbool.h> +#include <string.h> +#include <inttypes.h> +#include <assert.h> + +#include "minmax.h" + +#include "internal.h" + +struct nbdkit_extents { + struct nbdkit_extent *extents; + size_t nr_extents, allocated; + uint64_t start; +}; + +struct nbdkit_extents * +nbdkit_extents_new (uint64_t start) +{ + struct nbdkit_extents *r; + + if (start >= INT64_MAX) { + nbdkit_error ("nbdkit_extents_new: start (%" PRIu64 ") > INT64_MAX", + start); + retur...

...covered by the extents object, rather than the number of extent objects in the array. Would calling it 'nbdkit_extents_count' be any easier to understand? > +++ b/server/extents.c > @@ -0,0 +1,171 @@ > +struct nbdkit_extents { > + struct nbdkit_extent *extents; > + size_t nr_extents, allocated; > + uint64_t start; > +}; Is it also worth tracking cumulative length covered by extents? Tracking it would give us an O(1) instead of O(n) answer to "how many bytes did the plugin tell us about" - which MAY matter to filters that want to append additional data about a...

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all