search for: valid_rang

...ry/retry.c b/filters/retry/retry.c > index 840d7383..cf8f5246 100644 > --- a/filters/retry/retry.c > +++ b/filters/retry/retry.c > @@ -148,6 +148,17 @@ struct retry_data { > int delay; /* Seconds to wait before retrying. */ > }; > > +static bool > +valid_range (struct nbdkit_next_ops *next_ops, void *nxdata, > + uint32_t count, uint64_t offset, bool is_write, int *err) > +{ > + if ((int64_t) offset + count > next_ops->get_size (nxdata)) { > + *err = is_write ? ENOSPC : EIO; > + return false; > + } > + retu...

...d, 23 insertions(+) diff --git a/filters/retry/retry.c b/filters/retry/retry.c index 840d7383..cf8f5246 100644 --- a/filters/retry/retry.c +++ b/filters/retry/retry.c @@ -148,6 +148,17 @@ struct retry_data { int delay; /* Seconds to wait before retrying. */ }; +static bool +valid_range (struct nbdkit_next_ops *next_ops, void *nxdata, + uint32_t count, uint64_t offset, bool is_write, int *err) +{ + if ((int64_t) offset + count > next_ops->get_size (nxdata)) { + *err = is_write ? ENOSPC : EIO; + return false; + } + return true; +} + static bool do_retr...

...rejecting with EINVAL is still okay] - returning EPERM (aka EROFS) for read-only exports should probably take precedence over anything else - out-of-bounds WRITE and WRITE_ZEROES should fail with ENOSPC, not EIO - out-of-bounds READ and TRIM should fail with EINVAL, not EIO We also had dead code: valid_range() and validate_request() cannot return -1. Make these functions return bool instead. And finally, fix a comment typo. Signed-off-by: Eric Blake <eblake@redhat.com> --- src/connections.c | 53 ++++++++++++++++++++++++----------------------------- 1 file changed, 24 insertions(+), 29 delet...

...= 301 ; lon = 401 ; time = UNLIMITED ; // (80 currently) variables: float lat(lat) ; lat:long_name = "latitude" ; lat:standard_name = "latitude" ; lat:units = "degrees_north" ; lat:valid_range = -60., 60. ; float lon(lon) ; lon:long_name = "longitude" ; lon:standard_name = "longitude" ; lon:units = "degrees_east" ; lon:valid_range = -100., 45. ; double sst(time, lat, lon) ;...

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to

I still don't have .prepare/.finalize working cleanly across reopen, but did find a nasty bug where a botched assertion means we failed to notice reads beyond EOF in both the xz and retry filter. Refactoring backend.c will make .finalize work easier. Eric Blake (5): xz: Avoid reading beyond EOF retry: Check size before transactions tests: Test retry when get_size values change

Op 2014-06-20 om 15:56 schreef Ady: > > The Perl variant, isohybrid.in, seems to be getting left behind > regarding several patches. I don't recall whether there is at least > some mention in the isohybrid docs about the existence of 2 variants > included in Syslinux (and that is in addition to other isohybrid > methods outside Syslinux). Is there any reference? >

...rt, end); > + errno = ERANGE; > + return NULL; > + } > + > + /* 0-length ranges are possible, so start == end is not an error. */ > + if (start > end) { The protocol declares them to be unspecified behavior (so a portable client shouldn't be doing it). Doesn't valid_range() in protocol.c already filter out 0-length requests from the client? Thus, I'm wondering if this should be >= instead of > > +int > +nbdkit_add_extent (struct nbdkit_extents *exts, > + uint64_t offset, uint64_t length, uint32_t type) > +{ > + uint64_...

...cmd); + return true; + } + if (flags & NBDKIT_FLAG_FUA) { + assert (h->can_fua >= 0); + if (h->can_fua == 0) { + nbdkit_error ("invalid request: %s: FUA flag not supported", cmd); + return true; + } + } + return false; +} + +static bool +invalid_range (struct backend *b, struct connection *conn, const char *cmd, + uint64_t offset, uint32_t count) +{ + struct b_conn_handle *h = &conn->handles[b->i]; + + assert (h->exportsize >= 0); + if (!count || offset > h->exportsize || offset + count > h->exportsi...

...portsize = (uint64_t) r; - conn->exportsize = exportsize; gflags = 0; if (protocol_compute_eflags (conn, &eflags) < 0) diff --git a/server/protocol.c b/server/protocol.c index 72efcaa6..06f1ee15 100644 --- a/server/protocol.c +++ b/server/protocol.c @@ -53,8 +53,9 @@ static bool valid_range (struct connection *conn, uint64_t offset, uint32_t count) { - uint64_t exportsize = conn->exportsize; + uint64_t exportsize = backend_get_size (backend, conn); + assert (exportsize <= INT64_MAX); /* Guaranteed by negotiation phase */ return count > 0 && offset <= expor...

...the end range to avoid internal > errors)? Extent maps themselves are independent of the size of the plugin, and the foreach function will let you put any range there you want. However the server won't accept any NBD_CMD_BLOCK_STATUS request with a range beyond the end of the export size (valid_range in server/protocol.c), and so the core server code should not use a range which is outside the file (block_status_final_map in the same file). >From the point of view of filters that might call the foreach function, they shouldn't choose a range which is outside the offset/count passed to...

...; - - return 0; -} - -static int -negotiate_handshake (struct connection *conn) -{ - int r; - - lock_request (conn); - if (!newstyle) - r = _negotiate_handshake_oldstyle (conn); - else - r = _negotiate_handshake_newstyle (conn); - unlock_request (conn); - - return r; -} - -static bool -valid_range (struct connection *conn, uint64_t offset, uint32_t count) -{ - uint64_t exportsize = conn->exportsize; - - return count > 0 && offset <= exportsize && offset + count <= exportsize; -} - -static bool -validate_request (struct connection *conn, - uint1...

...stdint.h> +#include <stdbool.h> #include <inttypes.h> #include <string.h> #include <unistd.h> @@ -78,6 +79,7 @@ validate_request (struct connection *conn, case NBD_CMD_WRITE: case NBD_CMD_TRIM: case NBD_CMD_WRITE_ZEROES: + case NBD_CMD_BLOCK_STATUS: if (!valid_range (conn, offset, count)) { /* XXX Allow writes to extend the disk? */ nbdkit_error ("invalid request: %s: offset and count are out of range: " @@ -106,7 +108,8 @@ validate_request (struct connection *conn, } /* Validate flags */ - if (flags & ~(NBD_CMD_FLAG_FUA |...

These are a couple of patches in preparation for the Block Status implementation. While the patches (especially the second one) are very large they are really just elementary code motion. Rich.

On 3/19/19 11:34 AM, Richard W.M. Jones wrote: > This pair of calls allows plugins to describe which extents in the > virtual disk are allocated, holes or zeroes. > --- > + void nbdkit_extents_free (struct nbdkit_extents_map *); > + > +Frees an existing extents map. Is this like free() where it is safe to call on NULL? > + > +=head3 Iterating over nbdkit_extents_map

...stdint.h> +#include <stdbool.h> #include <inttypes.h> #include <string.h> #include <unistd.h> @@ -78,6 +79,7 @@ validate_request (struct connection *conn, case NBD_CMD_WRITE: case NBD_CMD_TRIM: case NBD_CMD_WRITE_ZEROES: + case NBD_CMD_BLOCK_STATUS: if (!valid_range (conn, offset, count)) { /* XXX Allow writes to extend the disk? */ nbdkit_error ("invalid request: %s: offset and count are out of range: " @@ -106,7 +108,8 @@ validate_request (struct connection *conn, } /* Validate flags */ - if (flags & ~(NBD_CMD_FLAG_FUA |...

The upstream protocol recently promoted NBD_CMD_WRITE_ZEROES from experimental to a documented extension. Exposing support for this allows plugin writers to create sparse files when driven by a client that knows how to use the extension; meanwhile, even if a plugin does not support this extension, the server benefits from less network traffic from the client. Eric Blake (5): protocol: Support

With some crufty sed scripts we can generate functions that map from NBD protocol flags (eg. NBD_CMD_READ) to strings ("NBD_CMD_READ"). This works on GNU sed and with FreeBSD, also with GNU sed's --posix option, so I guess the sed code is POSIX-compatible. Rich.

It's easy to use the sh script to demonstrate that nbdkit is inefficiently calling into .get_size, .can_fua, and friends more than necessary. We've also commented on the list in the past that it would be nice to ensure that when filters call into next_ops, they are not violating constraints (as we've have to fix several bugs in the past where we did not have such checking to protect

Tested via: term1$ qemu-nbd -k $PWD/sock -t -f raw -x foo junk --trace=nbd_\* term2$ ./nbdkit -f -v -e bar nbd socket=$PWD/sock export=foo term3$ qemu-io -t none -f raw nbd://localhost:10809/bar --trace=nbd_\* and checking the traces to see that 'w 0 1' vs. 'w -f 0 1' was able to influence whether the FUA flag showed up at the server in term1. Still to go: figure out how to