search for: name_of_nbd_rep

...nexpected. Either the server sent a legitimate error or an + unexpected reply, but either way, we can't connect. */ + if (NBD_REP_IS_ERR (reply.reply)) + if (reply.replylen) + nbdkit_error ("server rejected NBD_OPT_GO with %s: %s", + name_of_nbd_rep (reply.reply), buffer); + else + nbdkit_error ("server rejected NBD_OPT_GO with %s", + name_of_nbd_rep (reply.reply)); + else + nbdkit_error ("server used unexpected reply %s to NBD_OPT_GO", + name_of_nbd_re...

...efine NBD_OPT_EXPORT_NAME 1 #define NBD_OPT_ABORT 2 #define NBD_OPT_LIST 3 @@ -113,7 +110,6 @@ extern const char *name_of_nbd_opt (int); #define NBD_REP_ERR(val) (0x80000000 | (val)) #define NBD_REP_IS_ERR(val) (!!((val) & 0x80000000)) -extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 #define NBD_REP_SERVER 2 #define NBD_REP_INFO 3 @@ -124,7 +120,6 @@ extern const char *name_of_nbd_rep (int); #define NBD_REP_ERR_PLATFORM NBD_REP_ERR (4) #define NBD_REP_ERR_TLS_REQD NBD_REP_ERR (5) -extern const char *name_of_nbd_info (in...

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

Updated based on other changes that have happened in the meantime: - rely more on cleanup.h (throughout) - split structured read for easier review (patch 2 and 3 were combined in v1) - rely on nbdkit not leaking a server's partial answer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol

...ep.structured.flags); - rep.structured.type = be16toh (rep.structured.type); - rep.structured.length = be32toh (rep.structured.length); - nbdkit_debug ("received structured reply %s for cookie %#" PRIx64 - ", payload length %" PRId32, - name_of_nbd_reply_type (rep.structured.type), - rep.structured.handle, rep.structured.length); - if (rep.structured.length > 64 * 1024 * 1024) { - nbdkit_error ("structured reply length is suspiciously large: %" PRId32, - rep.structured.length); - retur...

...ep.structured.flags); - rep.structured.type = be16toh (rep.structured.type); - rep.structured.length = be32toh (rep.structured.length); - nbdkit_debug ("received structured reply %s for cookie %#" PRIx64 - ", payload length %" PRId32, - name_of_nbd_reply_type (rep.structured.type), - rep.structured.handle, rep.structured.length); - if (rep.structured.length > 64 * 1024 * 1024) { - nbdkit_error ("structured reply length is suspiciously large: %" PRId32, - rep.structured.length); - retur...

...ep.structured.flags); - rep.structured.type = be16toh (rep.structured.type); - rep.structured.length = be32toh (rep.structured.length); - nbdkit_debug ("received structured reply %s for cookie %#" PRIx64 - ", payload length %" PRId32, - name_of_nbd_reply_type (rep.structured.type), - rep.structured.handle, rep.structured.length); - if (rep.structured.length > 64 * 1024 * 1024) { - nbdkit_error ("structured reply length is suspiciously large: %" PRId32, - rep.structured.length); - retur...

...le handshake only). */ +extern const char *name_of_nbd_opt (int); #define NBD_OPT_EXPORT_NAME 1 #define NBD_OPT_ABORT 2 #define NBD_OPT_LIST 3 @@ -101,6 +104,7 @@ struct fixed_new_option_reply { #define NBD_OPT_INFO 6 #define NBD_OPT_GO 7 +extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 #define NBD_REP_SERVER 2 #define NBD_REP_INFO 3 @@ -110,6 +114,7 @@ struct fixed_new_option_reply { #define NBD_REP_ERR_PLATFORM 0x80000004 #define NBD_REP_ERR_TLS_REQD 0x80000005 +extern const char *name_of_nbd_info (int); #define NBD_INF...

...+++ b/server/protocol.h @@ -105,6 +105,8 @@ extern const char *name_of_nbd_opt (int); #define NBD_OPT_INFO 6 #define NBD_OPT_GO 7 #define NBD_OPT_STRUCTURED_REPLY 8 +#define NBD_OPT_LIST_META_CONTEXT 9 +#define NBD_OPT_SET_META_CONTEXT 10 extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 diff --git a/server/connections.c b/server/connections.c index aeb27f8..7e32f00 100644 --- a/server/connections.c +++ b/server/connections.c @@ -926,6 +926,90 @@ _negotiate_handshake_newstyle_options (struct connection *conn) conn->structured_replies...

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

libnbd-0.1.2-1 is now available in Fedora 29/30 updates-testing, although it was not compiled against libxml2 so it lacks uri support (I ended up testing patch 4 with a self-built libnbd). Diffs since v1 - rebase to master, bump from libnbd 0.1 to 0.1.2, add URI support, better timing results Still not done - patch 5 needs associated tests Eric Blake (5): nbd: Check for libnbd nbd:

We should have only one NBD protocol file. Let's make nbdkit's version the canonical one, and use it in libnbd. Rich.

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on

...o.c */ #define root_tls_certificates_dir sysconfdir "/pki/" PACKAGE_NAME extern void crypto_init (bool tls_set_on_cli); diff --git a/server/protocol.h b/server/protocol.h index 06b917e..a7de2f0 100644 --- a/server/protocol.h +++ b/server/protocol.h @@ -112,6 +112,7 @@ extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 #define NBD_REP_SERVER 2 #define NBD_REP_INFO 3 +#define NBD_REP_META_CONTEXT 4 #define NBD_REP_ERR_UNSUP 0x80000001 #define NBD_REP_ERR_POLICY 0x80000002 #define NBD_REP_ERR_INVALID 0x80000003 @@ -128,6 +129,18 @@ struct fixed_new_opt...

...o.c */ #define root_tls_certificates_dir sysconfdir "/pki/" PACKAGE_NAME extern void crypto_init (bool tls_set_on_cli); diff --git a/server/protocol.h b/server/protocol.h index 4fe3c75..a7de2f0 100644 --- a/server/protocol.h +++ b/server/protocol.h @@ -112,6 +112,7 @@ extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 #define NBD_REP_SERVER 2 #define NBD_REP_INFO 3 +#define NBD_REP_META_CONTEXT 4 #define NBD_REP_ERR_UNSUP 0x80000001 #define NBD_REP_ERR_POLICY 0x80000002 #define NBD_REP_ERR_INVALID 0x80000003 @@ -128,6 +129,18 @@ struct fixed_new_opt...

...7 +#define NBD_OPT_EXPORT_NAME 1 +#define NBD_OPT_ABORT 2 +#define NBD_OPT_LIST 3 +#define NBD_OPT_STARTTLS 5 +#define NBD_OPT_INFO 6 +#define NBD_OPT_GO 7 +#define NBD_OPT_STRUCTURED_REPLY 8 extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 @@ -144,15 +145,49 @@ struct request { uint32_t count; /* Request length. */ } __attribute__((packed)); -/* Reply (server -> client). */ -struct reply { - uint32_t magic; /* NBD_REPLY_MAGIC. */ +/* Simple reply (server -&g...

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.

Not sure what version we're up to, but this reimplements extents using the new simpler structure described in this thread: https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html I also fixed most of the things that Eric pointed out in the previous review, although I need to go back over his replies and check I've got everything. This needs a bit more testing. However the

I'm not sure exactly which version we're up to, but let's say it's version 4. I'm a lot happier with this version: - all filters have been reviewed and changed where I think that's necessary - can_extents is properly defined and implemented now - NBD protocol is followed - I believe it addresses all previous review points where possible The "only" thing

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