| Message ID | 20190815112708.11474-1-wipawel@amazon.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [lp-metadata,1/3] livepatch: Add support for modules .modinfo section metadata | expand |
Hi, I am not going to answer on the patch itself but the process. Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This is making difficult to know that all the patches belongs to the same series. In general, all patches are send as in-reply-to the cover letter. So all the patches sticks together in one thread. The cover letter can be generated via git format-patch --cover-letter. Threading is done automatically with git-send-email when all the patches as passed in arguments. For more details how to do it, you can read: https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series Cheers, On 15/08/2019 12:27, Pawel Wieczorkiewicz wrote: > The payloads' name strings can be of arbitrary size (typically small > with an upper bound of XEN_LIVEPATCH_NAME_SIZE). > Current implementation of the list operation interface allows to copy > names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual > size and enforces space allocation requirements on userland tools. > > To unify and simplify the interface, handle the name strings of > arbitrary size by copying them in adhering chunks to the userland. > In order to let the userland allocate enough space for the incoming > data add an auxiliary interface xc_livepatch_list_get_sizes() that > provides the current number of payload entries and the total size of > all name strings. This is achieved by extending the sysctl list > interface with an extra fields: name_total_size. > > The xc_livepatch_list_get_sizes() issues the livepatch sysctl list > operation with the nr field set to 0. In this mode the operation > returns the number of payload entries and calculates the total sizes > for all payloads' names. > When the sysctl operation is issued with a non-zero nr field (for > instance with a value obtained earlier with the prior call to the > xc_livepatch_list_get_sizes()) the new field name_total_size provides > the total size of actually copied data. > > Extend the libxc to handle the name back-to-back data transfers. > > The xen-livepatch tool is modified to start the list operation with a > call to the xc_livepatch_list_get_sizes() to obtain the actual number > of payloads as well as the necessary space for names. > The tool now always requests the actual number of entries and leaves > the preemption handling to the libxc routine. The libxc still returns > 'done' and 'left' parameters with the same semantic allowing the tool > to detect anomalies and react to them. At the moment it is expected > that the tool receives the exact number of entires as requested. > The xen-livepatch tool has been also modified to handle the name > back-to-back transfers correctly. > > Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de> > Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com> > Reviewed-by: Bjoern Doebel <doebel@amazon.de> > Reviewed-by: Martin Pohlack <mpohlack@amazon.de> > --- > tools/libxc/include/xenctrl.h | 49 ++++++++++++------ > tools/libxc/xc_misc.c | 100 ++++++++++++++++++++++++++++--------- > tools/misc/xen-livepatch.c | 112 ++++++++++++++++++++++-------------------- > xen/common/livepatch.c | 31 +++++++++--- > xen/include/public/sysctl.h | 15 +++--- > 5 files changed, 204 insertions(+), 103 deletions(-) > > diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h > index 725697c132..e0ebb586b6 100644 > --- a/tools/libxc/include/xenctrl.h > +++ b/tools/libxc/include/xenctrl.h > @@ -2560,7 +2560,25 @@ int xc_livepatch_get(xc_interface *xch, > xen_livepatch_status_t *status); > > /* > - * The heart of this function is to get an array of xen_livepatch_status_t. > + * Get a number of available payloads and get actual total size of > + * the payloads' name array. > + * > + * This functions is typically executed first before the xc_livepatch_list() > + * to obtain the sizes and correctly allocate all necessary data resources. > + * > + * The return value is zero if the hypercall completed successfully. > + * > + * If there was an error performing the sysctl operation, the return value > + * will contain the hypercall error code value. > + */ > +int xc_livepatch_list_get_sizes(xc_interface *xch, unsigned int *nr, > + uint64_t *name_total_size); > + > +/* git-send-email can do that for you. 1) Any series (i.e more than one patch) should contain a cover letter 2) > + * The heart of this function is to get an array of the following objects: > + * - xen_livepatch_status_t: states and return codes of payloads > + * - name: names of payloads > + * - len: lengths of corresponding payloads' names > * > * However it is complex because it has to deal with the hypervisor > * returning some of the requested data or data being stale > @@ -2571,21 +2589,20 @@ int xc_livepatch_get(xc_interface *xch, > * 'left' are also updated with the number of entries filled out > * and respectively the number of entries left to get from hypervisor. > * > - * It is expected that the caller of this function will take the > - * 'left' and use the value for 'start'. This way we have an > - * cursor in the array. Note that the 'info','name', and 'len' will > - * be updated at the subsequent calls. > + * It is expected that the caller of this function will first issue the > + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names > + * as well as the current number of payload entries. > + * The total sizes are required and supplied via the 'name_total_size' > + * parameter. > * > - * The 'max' is to be provided by the caller with the maximum > - * number of entries that 'info', 'name', and 'len' arrays can > - * be filled up with. > - * > - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE > - * length. > + * The 'max' is to be provided by the caller with the maximum number of > + * entries that 'info', 'name', 'len' arrays can be filled up with. > * > * Each entry in the 'info' array is expected to be of xen_livepatch_status_t > * structure size. > * > + * Each entry in the 'name' array may have an arbitrary size. > + * > * Each entry in the 'len' array is expected to be of uint32_t size. > * > * The return value is zero if the hypercall completed successfully. > @@ -2597,10 +2614,12 @@ int xc_livepatch_get(xc_interface *xch, > * will contain the number of entries that had been succesfully > * retrieved (if any). > */ > -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, > - xen_livepatch_status_t *info, char *name, > - uint32_t *len, unsigned int *done, > - unsigned int *left); > +int xc_livepatch_list(xc_interface *xch, const unsigned int max, > + const unsigned int start, > + struct xen_livepatch_status *info, > + char *name, uint32_t *len, > + const uint64_t name_total_size, > + unsigned int *done, unsigned int *left); > > /* > * The operations are asynchronous and the hypervisor may take a while > diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c > index a8e9e7d1e2..d787f3f29f 100644 > --- a/tools/libxc/xc_misc.c > +++ b/tools/libxc/xc_misc.c > @@ -662,7 +662,48 @@ int xc_livepatch_get(xc_interface *xch, > } > > /* > - * The heart of this function is to get an array of xen_livepatch_status_t. > + * Get a number of available payloads and get actual total size of > + * the payloads' name array. > + * > + * This functions is typically executed first before the xc_livepatch_list() > + * to obtain the sizes and correctly allocate all necessary data resources. > + * > + * The return value is zero if the hypercall completed successfully. > + * > + * If there was an error performing the sysctl operation, the return value > + * will contain the hypercall error code value. > + */ > +int xc_livepatch_list_get_sizes(xc_interface *xch, unsigned int *nr, > + uint64_t *name_total_size) > +{ > + DECLARE_SYSCTL; > + int rc; > + > + if ( !nr || !name_total_size ) > + { > + errno = EINVAL; > + return -1; > + } > + > + memset(&sysctl, 0, sizeof(sysctl)); > + sysctl.cmd = XEN_SYSCTL_livepatch_op; > + sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST; > + > + rc = do_sysctl(xch, &sysctl); > + if ( rc ) > + return rc; > + > + *nr = sysctl.u.livepatch.u.list.nr; > + *name_total_size = sysctl.u.livepatch.u.list.name_total_size; > + > + return 0; > +} > + > +/* > + * The heart of this function is to get an array of the following objects: > + * - xen_livepatch_status_t: states and return codes of payloads > + * - name: names of payloads > + * - len: lengths of corresponding payloads' names > * > * However it is complex because it has to deal with the hypervisor > * returning some of the requested data or data being stale > @@ -673,21 +714,20 @@ int xc_livepatch_get(xc_interface *xch, > * 'left' are also updated with the number of entries filled out > * and respectively the number of entries left to get from hypervisor. > * > - * It is expected that the caller of this function will take the > - * 'left' and use the value for 'start'. This way we have an > - * cursor in the array. Note that the 'info','name', and 'len' will > - * be updated at the subsequent calls. > + * It is expected that the caller of this function will first issue the > + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names > + * as well as the current number of payload entries. > + * The total sizes are required and supplied via the 'name_total_size' > + * parameter. > * > - * The 'max' is to be provided by the caller with the maximum > - * number of entries that 'info', 'name', and 'len' arrays can > - * be filled up with. > - * > - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE > - * length. > + * The 'max' is to be provided by the caller with the maximum number of > + * entries that 'info', 'name', 'len' arrays can be filled up with. > * > * Each entry in the 'info' array is expected to be of xen_livepatch_status_t > * structure size. > * > + * Each entry in the 'name' array may have an arbitrary size. > + * > * Each entry in the 'len' array is expected to be of uint32_t size. > * > * The return value is zero if the hypercall completed successfully. > @@ -699,11 +739,12 @@ int xc_livepatch_get(xc_interface *xch, > * will contain the number of entries that had been succesfully > * retrieved (if any). > */ > -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, > +int xc_livepatch_list(xc_interface *xch, const unsigned int max, > + const unsigned int start, > struct xen_livepatch_status *info, > char *name, uint32_t *len, > - unsigned int *done, > - unsigned int *left) > + const uint64_t name_total_size, > + unsigned int *done, unsigned int *left) > { > int rc; > DECLARE_SYSCTL; > @@ -714,27 +755,33 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, > uint32_t max_batch_sz, nr; > uint32_t version = 0, retries = 0; > uint32_t adjust = 0; > - ssize_t sz; > + off_t name_off = 0; > + uint64_t name_sz; > > - if ( !max || !info || !name || !len ) > + if ( !max || !info || !name || !len || !done || !left ) > { > errno = EINVAL; > return -1; > } > > + if ( name_total_size == 0 ) > + { > + errno = ENOENT; > + return -1; > + } > + > + memset(&sysctl, 0, sizeof(sysctl)); > sysctl.cmd = XEN_SYSCTL_livepatch_op; > sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST; > - sysctl.u.livepatch.pad = 0; > - sysctl.u.livepatch.u.list.version = 0; > sysctl.u.livepatch.u.list.idx = start; > - sysctl.u.livepatch.u.list.pad = 0; > > max_batch_sz = max; > - /* Convience value. */ > - sz = sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE; > + name_sz = name_total_size; > *done = 0; > *left = 0; > do { > + uint64_t _name_sz; > + > /* > * The first time we go in this loop our 'max' may be bigger > * than what the hypervisor is comfortable with - hence the first > @@ -754,11 +801,11 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, > sysctl.u.livepatch.u.list.nr = nr; > /* Fix the size (may vary between hypercalls). */ > HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info)); > - HYPERCALL_BOUNCE_SET_SIZE(name, nr * nr); > + HYPERCALL_BOUNCE_SET_SIZE(name, name_sz); > HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len)); > /* Move the pointer to proper offset into 'info'. */ > (HYPERCALL_BUFFER(info))->ubuf = info + *done; > - (HYPERCALL_BUFFER(name))->ubuf = name + (sz * *done); > + (HYPERCALL_BUFFER(name))->ubuf = name + name_off; > (HYPERCALL_BUFFER(len))->ubuf = len + *done; > /* Allocate memory. */ > rc = xc_hypercall_bounce_pre(xch, info); > @@ -827,14 +874,19 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, > break; > } > *left = sysctl.u.livepatch.u.list.nr; /* Total remaining count. */ > + _name_sz = sysctl.u.livepatch.u.list.name_total_size; /* Total received name size. */ > /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */ > HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info))); > - HYPERCALL_BOUNCE_SET_SIZE(name, (rc * sz)); > + HYPERCALL_BOUNCE_SET_SIZE(name, _name_sz); > HYPERCALL_BOUNCE_SET_SIZE(len, (rc * sizeof(*len))); > /* Bounce the data and free the bounce buffer. */ > xc_hypercall_bounce_post(xch, info); > xc_hypercall_bounce_post(xch, name); > xc_hypercall_bounce_post(xch, len); > + > + name_sz -= _name_sz; > + name_off += _name_sz; > + > /* And update how many elements of info we have copied into. */ > *done += rc; > /* Update idx. */ > diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c > index a37b2457ff..8ac3d567fc 100644 > --- a/tools/misc/xen-livepatch.c > +++ b/tools/misc/xen-livepatch.c > @@ -64,14 +64,14 @@ static const char *state2str(unsigned int state) > return names[state]; > } > > -/* This value was choosen adhoc. It could be 42 too. */ > -#define MAX_LEN 11 > static int list_func(int argc, char *argv[]) > { > - unsigned int idx, done, left, i; > + unsigned int nr, done, left, i; > xen_livepatch_status_t *info = NULL; > char *name = NULL; > uint32_t *len = NULL; > + uint64_t name_total_size; > + off_t name_off; > int rc = ENOMEM; > > if ( argc ) > @@ -79,65 +79,73 @@ static int list_func(int argc, char *argv[]) > show_help(); > return -1; > } > - idx = left = 0; > - info = malloc(sizeof(*info) * MAX_LEN); > - if ( !info ) > - return rc; > - name = malloc(sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE * MAX_LEN); > - if ( !name ) > + done = left = 0; > + > + rc = xc_livepatch_list_get_sizes(xch, &nr, &name_total_size); > + if ( rc ) > { > - free(info); > + rc = errno; > + fprintf(stderr, "Failed to get list sizes.\n" > + "Error %d: %s\n", > + rc, strerror(rc)); > return rc; > } > - len = malloc(sizeof(*len) * MAX_LEN); > - if ( !len ) { > - free(name); > - free(info); > + > + if ( nr == 0 ) > + { > + fprintf(stdout, "Nothing to list\n"); > + return 0; > + } > + > + info = malloc(nr * sizeof(*info)); > + if ( !info ) > return rc; > + > + name = malloc(name_total_size * sizeof(*name)); > + if ( !name ) > + goto error_name; > + > + len = malloc(nr * sizeof(*len)); > + if ( !len ) > + goto error_len; > + > + memset(info, 'A', nr * sizeof(*info)); > + memset(name, 'B', name_total_size * sizeof(*name)); > + memset(len, 'C', nr * sizeof(*len)); > + name_off = 0; > + > + rc = xc_livepatch_list(xch, nr, 0, info, name, len, name_total_size, &done, &left); > + if ( rc || done != nr || left > 0) > + { > + rc = errno; > + fprintf(stderr, "Failed to list %d/%d.\n" > + "Error %d: %s\n", > + left, nr, rc, strerror(rc)); > + goto error; > } > > - do { > - done = 0; > - /* The memset is done to catch errors. */ > - memset(info, 'A', sizeof(*info) * MAX_LEN); > - memset(name, 'B', sizeof(*name) * MAX_LEN * XEN_LIVEPATCH_NAME_SIZE); > - memset(len, 'C', sizeof(*len) * MAX_LEN); > - rc = xc_livepatch_list(xch, MAX_LEN, idx, info, name, len, &done, &left); > - if ( rc ) > - { > - rc = errno; > - fprintf(stderr, "Failed to list %d/%d.\n" > - "Error %d: %s\n", > - idx, left, rc, strerror(rc)); > - break; > - } > - if ( !idx ) > - fprintf(stdout," ID | status\n" > - "----------------------------------------+------------\n"); > + fprintf(stdout," ID | status\n" > + "----------------------------------------+------------\n"); > > - for ( i = 0; i < done; i++ ) > - { > - unsigned int j; > - uint32_t sz; > - char *str; > - > - sz = len[i]; > - str = name + (i * XEN_LIVEPATCH_NAME_SIZE); > - for ( j = sz; j < XEN_LIVEPATCH_NAME_SIZE; j++ ) > - str[j] = '\0'; > - > - printf("%-40s| %s", str, state2str(info[i].state)); > - if ( info[i].rc ) > - printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc)); > - else > - puts(""); > - } > - idx += done; > - } while ( left ); > + for ( i = 0; i < done; i++ ) > + { > + char *name_str = name + name_off; > + > + printf("%-40.*s| %s", len[i], name_str, state2str(info[i].state)); > + if ( info[i].rc ) > + printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc)); > + else > + puts(""); > + > + name_off += len[i]; > + } > > +error: > + free(len); > +error_len: > free(name); > +error_name: > free(info); > - free(len); > return rc; > } > #undef MAX_LEN > diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c > index f88cf3bc73..f486cb3021 100644 > --- a/xen/common/livepatch.c > +++ b/xen/common/livepatch.c > @@ -1163,7 +1163,6 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) > > if ( list->nr && > (!guest_handle_okay(list->status, list->nr) || > - !guest_handle_okay(list->name, XEN_LIVEPATCH_NAME_SIZE * list->nr) || > !guest_handle_okay(list->len, list->nr)) ) > return -EINVAL; > > @@ -1174,23 +1173,35 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) > return -EINVAL; > } > > + list->name_total_size = 0; > if ( list->nr ) > { > + uint64_t name_offset = 0; > + > list_for_each_entry( data, &payload_list, list ) > { > - uint32_t len; > + uint32_t name_len; > > if ( list->idx > i++ ) > continue; > > status.state = data->state; > status.rc = data->rc; > - len = strlen(data->name) + 1; > + > + name_len = strlen(data->name) + 1; > + list->name_total_size += name_len; > + > + if ( !guest_handle_subrange_okay(list->name, name_offset, > + name_offset + name_len - 1) ) > + { > + rc = -EINVAL; > + break; > + } > > /* N.B. 'idx' != 'i'. */ > - if ( __copy_to_guest_offset(list->name, idx * XEN_LIVEPATCH_NAME_SIZE, > - data->name, len) || > - __copy_to_guest_offset(list->len, idx, &len, 1) || > + if ( __copy_to_guest_offset(list->name, name_offset, > + data->name, name_len) || > + __copy_to_guest_offset(list->len, idx, &name_len, 1) || > __copy_to_guest_offset(list->status, idx, &status, 1) ) > { > rc = -EFAULT; > @@ -1198,11 +1209,19 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) > } > > idx++; > + name_offset += name_len; > > if ( (idx >= list->nr) || hypercall_preempt_check() ) > break; > } > } > + else > + { > + list_for_each_entry( data, &payload_list, list ) > + { > + list->name_total_size += strlen(data->name) + 1; > + } > + } > list->nr = payload_cnt - i; /* Remaining amount. */ > list->version = payload_version; > spin_unlock(&payload_lock); > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h > index 335e193712..b86804b7a6 100644 > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h > @@ -926,10 +926,11 @@ struct xen_sysctl_livepatch_get { > * > * If the hypercall returns an positive number, it is the number (up to `nr`) > * of the payloads returned, along with `nr` updated with the number of remaining > - * payloads, `version` updated (it may be the same across hypercalls. If it > - * varies the data is stale and further calls could fail). The `status`, > - * `name`, and `len`' are updated at their designed index value (`idx`) with > - * the returned value of data. > + * payloads, `version` updated (it may be the same across hypercalls. If it varies > + * the data is stale and further calls could fail) and the name_total_size > + * containing total size of transfered data for the array. > + * The `status`, `name`, `len` are updated at their designed index value (`idx`) > + * with the returned value of data. > * > * If the hypercall returns E2BIG the `nr` is too big and should be > * lowered. The upper limit of `nr` is left to the implemention. > @@ -952,11 +953,13 @@ struct xen_sysctl_livepatch_list { > amount of payloads and version. > OUT: How many payloads left. */ > uint32_t pad; /* IN: Must be zero. */ > + uint64_t name_total_size; /* OUT: Total size of all transfer names */ > XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status; /* OUT. Must have enough > space allocate for nr of them. */ > XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each member > - MUST XEN_LIVEPATCH_NAME_SIZE in size. > - Must have nr of them. */ > + may have an arbitrary length up to > + XEN_LIVEPATCH_NAME_SIZE bytes. Must have > + nr of them. */ > XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's. > Must have nr of them. */ > }; >
> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com> wrote: > > Hi, > > I am not going to answer on the patch itself but the process. > > Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. > > Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This is making difficult to know that all the patches belongs to the same series. In general, all patches are send as in-reply-to the cover letter. So all the patches sticks together in one thread. > > The cover letter can be generated via git format-patch --cover-letter. Threading is done automatically with git-send-email when all the patches as passed in arguments. > > For more details how to do it, you can read: > > https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series> > > Cheers, Hi Pawel, thank you for submitting the patch series. We had a couple of new starters recently who followed a similar pattern to you. As a result of this, I recently updated the following docs https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches> - Definitions and general workflow The bit which saves the most work is https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series> As for Julien's comment on the threading: see the --thread and --cover-letter option as described in the Sending a Patch Series https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git <https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git> - Basic Git commands fitting into the workflow, including how to deal with reviews https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit <https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit> - Basic StGit commands fitting into the workflow, including how to deal with reviews I have not had time to play with git series yet. If anyone in your team uses it let me know In any case: if you follow the instructions the entire submission process and dealing with review comments becomes much easier. As a newcomer, to contributing to Xen, I would greatly appreciate if you could let me know of any issues with the docs, such that we can fix them Regards Lars
Hi Lars, Julien, Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. Sorry for the mess… But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and livepatch-build-tools)? Best Regards, Pawel Wieczorkiewicz On 15. Aug 2019, at 16:58, Lars Kurth <lars.kurth.xen@gmail.com<mailto:lars.kurth.xen@gmail.com>> wrote: On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com<mailto:julien.grall@arm.com>> wrote: Hi, I am not going to answer on the patch itself but the process. Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This is making difficult to know that all the patches belongs to the same series. In general, all patches are send as in-reply-to the cover letter. So all the patches sticks together in one thread. The cover letter can be generated via git format-patch --cover-letter. Threading is done automatically with git-send-email when all the patches as passed in arguments. For more details how to do it, you can read: https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series Cheers, Hi Pawel, thank you for submitting the patch series. We had a couple of new starters recently who followed a similar pattern to you. As a result of this, I recently updated the following docs https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions and general workflow The bit which saves the most work is https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series As for Julien's comment on the threading: see the --thread and --cover-letter option as described in the Sending a Patch Series https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git commands fitting into the workflow, including how to deal with reviews https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit commands fitting into the workflow, including how to deal with reviews I have not had time to play with git series yet. If anyone in your team uses it let me know In any case: if you follow the instructions the entire submission process and dealing with review comments becomes much easier. As a newcomer, to contributing to Xen, I would greatly appreciate if you could let me know of any issues with the docs, such that we can fix them Regards Lars Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: > Hi Lars, Julien, Hi, > Thanks for the pointers, I will read them up and follow the recommendations with > my future contributions. > Sorry for the mess… > > But, let me ask first before reading the wikis, how do you prefer submitting > series that contain patches belonging to 2 distinct repos (e.g. xen and > livepatch-build-tools)? I can see two ways: 1) One series per project and mention in the cover letter that modifications are required in another project (with link/title). 2) Combine all the patches in one series and tag them differently. I.e [XEN] [LIVEPATCH]. 1) is preferable if you have a lot of patches in each repo. 2) can be handy if you have only a couple of patches for one repo. Cheers, > > Best Regards, > Pawel Wieczorkiewicz > > > >> On 15. Aug 2019, at 16:58, Lars Kurth <lars.kurth.xen@gmail.com >> <mailto:lars.kurth.xen@gmail.com>> wrote: >> >> >> >>> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com >>> <mailto:julien.grall@arm.com>> wrote: >>> >>> Hi, >>> >>> I am not going to answer on the patch itself but the process. >>> >>> Any series (i.e more than one patch) should contain a cover letter with a >>> rough summary of the goal of the series. >>> >>> Furthermore, this 3 patches series has been received as 3 separate threads >>> (i.e in-reply-to is missing). This is making difficult to know that all the >>> patches belongs to the same series. In general, all patches are send as >>> in-reply-to the cover letter. So all the patches sticks together in one thread. >>> >>> The cover letter can be generated via git format-patch --cover-letter. >>> Threading is done automatically with git-send-email when all the patches as >>> passed in arguments. >>> >>> For more details how to do it, you can read: >>> >>> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series >>> >>> Cheers, >> >> Hi Pawel, >> >> thank you for submitting the patch series. >> >> We had a couple of new starters recently who followed a similar pattern to >> you. As a result of this, I recently updated the following docs >> >> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions >> and general workflow >> The bit which saves the most work is >> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series >> As for Julien's comment on the threading: see the --thread and --cover-letter >> option as described in the Sending a Patch Series >> >> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git >> commands fitting into the workflow, including how to deal with reviews >> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit >> commands fitting into the workflow, including how to deal with reviews >> I have not had time to play with git series yet. If anyone in your team uses >> it let me know >> >> In any case: if you follow the instructions the entire submission process and >> dealing with review comments becomes much easier. >> >> As a newcomer, to contributing to Xen, I would greatly appreciate if you could >> let me know of any issues with the docs, such that we can fix them >> >> Regards >> Lars >> >> >> > > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >
On 8/15/19 4:29 PM, Julien Grall wrote: > > > On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >> Hi Lars, Julien, > > Hi, > >> Thanks for the pointers, I will read them up and follow the >> recommendations with my future contributions. >> Sorry for the mess… >> >> But, let me ask first before reading the wikis, how do you prefer >> submitting series that contain patches belonging to 2 distinct repos >> (e.g. xen and livepatch-build-tools)? > > I can see two ways: > > 1) One series per project and mention in the cover letter that > modifications are required in another project (with link/title). > 2) Combine all the patches in one series and tag them differently. I.e > [XEN] [LIVEPATCH]. > > 1) is preferable if you have a lot of patches in each repo. 2) can be > handy if you have only a couple of patches for one repo. 1 is also easier for automated tools (like patchew) to deal with. -George
> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de> wrote: > > Hi Lars, Julien, > > Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. > Sorry for the mess… It's not really a mess: it must have been quite a pain to put the mails together manually And it would become more painful for a second revision I have been through this myself > But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and livepatch-build-tools)? That's a good question and a very rare use-case. We split them, as all the tools such as git format-patch only work on one repo Applying patches also only works on a per repo basis So, I would send two series. But mention the relationship in the cover letter (and/or patch if it is a single one) The tools in the docs currently may not work on livepatch-build-tools.git * First: there is no MAINTAINERS file in livepatch-build-tools.git, which really should be added * Second: using xen.git:/scripts/add_maintainers.pl may not work when called from within livepatch-build-tools.git I am going to play with this and update the docs and if needed the tools accordingly You may have to improvise in the meantime: * Step 1 & 3 will work: Step 2, option 1 will probably not (which means until I have done this, you may have to follow option 2 and make sure that the right people are CC'ed) You can also use: https://patchew.org/Xen/ <https://patchew.org/Xen/>, https://patchwork.kernel.org/project/xen-devel/list/ <https://patchwork.kernel.org/project/xen-devel/list/> or https://lore.kernel.org/xen-devel/ <https://lore.kernel.org/xen-devel/> to track some of the changes. I have not had time to add this to the docs yet Lars > > Best Regards, > Pawel Wieczorkiewicz > > > >> On 15. Aug 2019, at 16:58, Lars Kurth <lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>> wrote: >> >> >> >>> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com <mailto:julien.grall@arm.com>> wrote: >>> >>> Hi, >>> >>> I am not going to answer on the patch itself but the process. >>> >>> Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. >>> >>> Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This is making difficult to know that all the patches belongs to the same series. In general, all patches are send as in-reply-to the cover letter. So all the patches sticks together in one thread. >>> >>> The cover letter can be generated via git format-patch --cover-letter. Threading is done automatically with git-send-email when all the patches as passed in arguments. >>> >>> For more details how to do it, you can read: >>> >>> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series> >>> >>> Cheers, >> >> Hi Pawel, >> >> thank you for submitting the patch series. >> >> We had a couple of new starters recently who followed a similar pattern to you. As a result of this, I recently updated the following docs >> >> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches> - Definitions and general workflow >> The bit which saves the most work is https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series> >> As for Julien's comment on the threading: see the --thread and --cover-letter option as described in the Sending a Patch Series >> >> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git <https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git> - Basic Git commands fitting into the workflow, including how to deal with reviews >> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit <https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit> - Basic StGit commands fitting into the workflow, including how to deal with reviews >> I have not had time to play with git series yet. If anyone in your team uses it let me know >> >> In any case: if you follow the instructions the entire submission process and dealing with review comments becomes much easier. >> >> As a newcomer, to contributing to Xen, I would greatly appreciate if you could let me know of any issues with the docs, such that we can fix them >> >> Regards >> Lars >> >> >> > > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > >
Hi George, On 15/08/2019 16:32, George Dunlap wrote: > On 8/15/19 4:29 PM, Julien Grall wrote: >> >> >> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >>> Hi Lars, Julien, >> >> Hi, >> >>> Thanks for the pointers, I will read them up and follow the >>> recommendations with my future contributions. >>> Sorry for the mess… >>> >>> But, let me ask first before reading the wikis, how do you prefer >>> submitting series that contain patches belonging to 2 distinct repos >>> (e.g. xen and livepatch-build-tools)? >> >> I can see two ways: >> >> 1) One series per project and mention in the cover letter that >> modifications are required in another project (with link/title). >> 2) Combine all the patches in one series and tag them differently. I.e >> [XEN] [LIVEPATCH]. >> >> 1) is preferable if you have a lot of patches in each repo. 2) can be >> handy if you have only a couple of patches for one repo. > > 1 is also easier for automated tools (like patchew) to deal with. Out of interest, in general developer will tend to cross-post those patches. So in what way this would make it easier? Cheers,
Thanks Julien. I will do that next time (unless you guys want me to re-send all this ;-)). BTW, I also pushed my changes onto the xenbits server: http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary I hope that makes navigation and dealing with the swarm of patches a bit easier. Best Regards, Pawel Wieczorkiewicz On 15. Aug 2019, at 17:29, Julien Grall <julien.grall@arm.com<mailto:julien.grall@arm.com>> wrote: On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: Hi Lars, Julien, Hi, Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. Sorry for the mess… But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and livepatch-build-tools)? I can see two ways: 1) One series per project and mention in the cover letter that modifications are required in another project (with link/title). 2) Combine all the patches in one series and tag them differently. I.e [XEN] [LIVEPATCH]. 1) is preferable if you have a lot of patches in each repo. 2) can be handy if you have only a couple of patches for one repo. Cheers, Best Regards, Pawel Wieczorkiewicz On 15. Aug 2019, at 16:58, Lars Kurth <lars.kurth.xen@gmail.com<mailto:lars.kurth.xen@gmail.com> <mailto:lars.kurth.xen@gmail.com>> wrote: On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com<mailto:julien.grall@arm.com> <mailto:julien.grall@arm.com>> wrote: Hi, I am not going to answer on the patch itself but the process. Any series (i.e more than one patch) should contain a cover letter with a rough summary of the goal of the series. Furthermore, this 3 patches series has been received as 3 separate threads (i.e in-reply-to is missing). This is making difficult to know that all the patches belongs to the same series. In general, all patches are send as in-reply-to the cover letter. So all the patches sticks together in one thread. The cover letter can be generated via git format-patch --cover-letter. Threading is done automatically with git-send-email when all the patches as passed in arguments. For more details how to do it, you can read: https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series Cheers, Hi Pawel, thank you for submitting the patch series. We had a couple of new starters recently who followed a similar pattern to you. As a result of this, I recently updated the following docs https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions and general workflow The bit which saves the most work is https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series As for Julien's comment on the threading: see the --thread and --cover-letter option as described in the Sending a Patch Series https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git commands fitting into the workflow, including how to deal with reviews https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit commands fitting into the workflow, including how to deal with reviews I have not had time to play with git series yet. If anyone in your team uses it let me know In any case: if you follow the instructions the entire submission process and dealing with review comments becomes much easier. As a newcomer, to contributing to Xen, I would greatly appreciate if you could let me know of any issues with the docs, such that we can fix them Regards Lars Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 -- Julien Grall Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com> wrote: > > > >> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de <mailto:wipawel@amazon.de>> wrote: >> >> Hi Lars, Julien, >> >> Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. >> Sorry for the mess… > > It's not really a mess: it must have been quite a pain to put the mails together manually > And it would become more painful for a second revision > I have been through this myself > >> But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and livepatch-build-tools)? > > That's a good question and a very rare use-case. We split them, as all the tools such as git format-patch only work on one repo > Applying patches also only works on a per repo basis > > So, I would send two series. But mention the relationship in the cover letter (and/or patch if it is a single one) > > The tools in the docs currently may not work on livepatch-build-tools.git > * First: there is no MAINTAINERS file in livepatch-build-tools.git, which really should be added > * Second: using xen.git:/scripts/add_maintainers.pl may not work when called from within livepatch-build-tools.git > > I am going to play with this and update the docs and if needed the tools accordingly > You may have to improvise in the meantime: > * Step 1 & 3 will work: Step 2, option 1 will probably not (which means until I have done this, you may have to follow option 2 and make sure that the right people are CC'ed) I can confirm that Step 2 does not work without some tools changes to scripts/add_maintainers.pl when called from within a non-xen.git repo And git send-email --to xen-devel@lists.xenproject.org --cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1 errors with ../xen.git/scripts/get_maintainer.pl: The current directory does not appear to be a Xen source tree. I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the actual Xen tree Lars
On 8/15/19 4:36 PM, Julien Grall wrote: > Hi George, > > On 15/08/2019 16:32, George Dunlap wrote: >> On 8/15/19 4:29 PM, Julien Grall wrote: >>> >>> >>> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >>>> Hi Lars, Julien, >>> >>> Hi, >>> >>>> Thanks for the pointers, I will read them up and follow the >>>> recommendations with my future contributions. >>>> Sorry for the mess… >>>> >>>> But, let me ask first before reading the wikis, how do you prefer >>>> submitting series that contain patches belonging to 2 distinct repos >>>> (e.g. xen and livepatch-build-tools)? >>> >>> I can see two ways: >>> >>> 1) One series per project and mention in the cover letter that >>> modifications are required in another project (with link/title). >>> 2) Combine all the patches in one series and tag them differently. >>> I.e >>> [XEN] [LIVEPATCH]. >>> >>> 1) is preferable if you have a lot of patches in each repo. 2) can be >>> handy if you have only a couple of patches for one repo. >> >> 1 is also easier for automated tools (like patchew) to deal with. > > Out of interest, in general developer will tend to cross-post those > patches. So in what way this would make it easier? If you have two separate series, then patchew will be able to handle one and not handle the other. If they're mixed in a single series, patchew won't be able to handle it at all. At the moment patchew doesn't do anything but give you a nice mbox / git branch to pull; but eventually the idea is that it will do some level of testing and give feedback (patch does/n't apply, patch does/n't build, patch does/n't pass smoke tests / &c). -George
Hi Lars, On 15/08/2019 16:46, Lars Kurth wrote: > > >> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com >> <mailto:lars.kurth.xen@gmail.com>> wrote: >> >> >> >>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de >>> <mailto:wipawel@amazon.de>> wrote: >>> >>> Hi Lars, Julien, >>> >>> Thanks for the pointers, I will read them up and follow the recommendations >>> with my future contributions. >>> Sorry for the mess… >> >> It's not really a mess: it must have been quite a pain to put the mails >> together manually >> And it would become more painful for a second revision >> I have been through this myself >> >>> But, let me ask first before reading the wikis, how do you prefer submitting >>> series that contain patches belonging to 2 distinct repos (e.g. xen and >>> livepatch-build-tools)? >> >> That's a good question and a very rare use-case. We split them, as all the >> tools such as git format-patch only work on one repo >> Applying patches also only works on a per repo basis >> >> So, I would send two series. But mention the relationship in the cover letter >> (and/or patch if it is a single one) >> >> The tools in the docs currently may not work on livepatch-build-tools.git >> * First: there is no MAINTAINERS file in livepatch-build-tools.git, which >> really should be added >> * Second: using xen.git:/scripts/add_maintainers.pl may not work when called >> from within livepatch-build-tools.git >> >> I am going to play with this and update the docs and if needed the tools >> accordingly >> You may have to improvise in the meantime: >> * Step 1 & 3 will work: Step 2, option 1 will probably not (which means until >> I have done this, you may have to follow option 2 and make sure that the right >> people are CC'ed) > > I can confirm that Step 2 does not work without some tools changes to > scripts/add_maintainers.pl when called from within a non-xen.git repo > > And > > git send-email --to xen-devel@lists.xenproject.org > <mailto:xen-devel@lists.xenproject.org> > --cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1 > > errors with > > ../xen.git/scripts/get_maintainer.pl: The current directory does not appear to > be a Xen source tree. > > I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the > actual Xen tree get_maintainer.pl relies on the current working directory to be the top of tree. At the moment, it checks various file are present (see top_of_tree) but I think it should be feasible to just relax it to just MAINTAINERS. The risk is a user may end up to call the wrong MAINTAINERS file if it messes up the current working directory (i.e calling for Xen patches from livepatch-tools). Not sure if this is a real concern though... Note that Linux has a similar check to ensure the user is on the right directory (i.e Cheers,
Hi George, On 15/08/2019 16:48, George Dunlap wrote: > On 8/15/19 4:36 PM, Julien Grall wrote: >> Hi George, >> >> On 15/08/2019 16:32, George Dunlap wrote: >>> On 8/15/19 4:29 PM, Julien Grall wrote: >>>> >>>> >>>> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >>>>> Hi Lars, Julien, >>>> >>>> Hi, >>>> >>>>> Thanks for the pointers, I will read them up and follow the >>>>> recommendations with my future contributions. >>>>> Sorry for the mess… >>>>> >>>>> But, let me ask first before reading the wikis, how do you prefer >>>>> submitting series that contain patches belonging to 2 distinct repos >>>>> (e.g. xen and livepatch-build-tools)? >>>> >>>> I can see two ways: >>>> >>>> 1) One series per project and mention in the cover letter that >>>> modifications are required in another project (with link/title). >>>> 2) Combine all the patches in one series and tag them differently. >>>> I.e >>>> [XEN] [LIVEPATCH]. >>>> >>>> 1) is preferable if you have a lot of patches in each repo. 2) can be >>>> handy if you have only a couple of patches for one repo. >>> >>> 1 is also easier for automated tools (like patchew) to deal with. >> >> Out of interest, in general developer will tend to cross-post those >> patches. So in what way this would make it easier? > > If you have two separate series, then patchew will be able to handle one > and not handle the other. If they're mixed in a single series, patchew > won't be able to handle it at all. At the moment patchew doesn't do > anything but give you a nice mbox / git branch to pull; but eventually > the idea is that it will do some level of testing and give feedback > (patch does/n't apply, patch does/n't build, patch does/n't pass smoke > tests / &c). Oh, so patchew will try to apply the series. If it does not fully apply, then it means the series does not target Xen, right? I haven't used much patchew so far, but it looks like I should give a try when committing/reviewing series :). Thank you for the explanation! Cheers,
> On 15 Aug 2019, at 16:58, Julien Grall <julien.grall@arm.com> wrote: > > Hi Lars, > > On 15/08/2019 16:46, Lars Kurth wrote: >>> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>> wrote: >>> >>> >>> >>>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de <mailto:wipawel@amazon.de>> wrote: >>>> >>>> Hi Lars, Julien, >>>> >>>> Thanks for the pointers, I will read them up and follow the recommendations with my future contributions. >>>> Sorry for the mess… >>> >>> It's not really a mess: it must have been quite a pain to put the mails together manually >>> And it would become more painful for a second revision >>> I have been through this myself >>> >>>> But, let me ask first before reading the wikis, how do you prefer submitting series that contain patches belonging to 2 distinct repos (e.g. xen and livepatch-build-tools)? >>> >>> That's a good question and a very rare use-case. We split them, as all the tools such as git format-patch only work on one repo >>> Applying patches also only works on a per repo basis >>> >>> So, I would send two series. But mention the relationship in the cover letter (and/or patch if it is a single one) >>> >>> The tools in the docs currently may not work on livepatch-build-tools.git >>> * First: there is no MAINTAINERS file in livepatch-build-tools.git, which really should be added >>> * Second: using xen.git:/scripts/add_maintainers.pl may not work when called from within livepatch-build-tools.git >>> >>> I am going to play with this and update the docs and if needed the tools accordingly >>> You may have to improvise in the meantime: >>> * Step 1 & 3 will work: Step 2, option 1 will probably not (which means until I have done this, you may have to follow option 2 and make sure that the right people are CC'ed) >> I can confirm that Step 2 does not work without some tools changes to scripts/add_maintainers.pl when called from within a non-xen.git repo >> And >> git send-email --to xen-devel@lists.xenproject.org <mailto:xen-devel@lists.xenproject.org> --cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1 >> errors with >> ../xen.git/scripts/get_maintainer.pl: The current directory does not appear to be a Xen source tree. >> I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the actual Xen tree > > get_maintainer.pl relies on the current working directory to be the top of tree. > > At the moment, it checks various file are present (see top_of_tree) but I think it should be feasible to just relax it to just MAINTAINERS. > > The risk is a user may end up to call the wrong MAINTAINERS file if it messes up the current working directory (i.e calling for Xen patches from livepatch-tools). Not sure if this is a real concern though... > > Note that Linux has a similar check to ensure the user is on the right directory (i.e I know, that's where we inherited that from. I suppose the issue is that the MAINTAINERS file format may be different in another tree and thus the tool may fall over. In any case: I have a patch which prints out a warning rather than abort I will send once I made corresponding change to get_maintainers.pl, which seems to have call locations to add_maintainers.pl hardcoded in it Lars
On 8/15/19 5:00 PM, Julien Grall wrote: > Hi George, > > On 15/08/2019 16:48, George Dunlap wrote: >> On 8/15/19 4:36 PM, Julien Grall wrote: >>> Hi George, >>> >>> On 15/08/2019 16:32, George Dunlap wrote: >>>> On 8/15/19 4:29 PM, Julien Grall wrote: >>>>> >>>>> >>>>> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote: >>>>>> Hi Lars, Julien, >>>>> >>>>> Hi, >>>>> >>>>>> Thanks for the pointers, I will read them up and follow the >>>>>> recommendations with my future contributions. >>>>>> Sorry for the mess… >>>>>> >>>>>> But, let me ask first before reading the wikis, how do you prefer >>>>>> submitting series that contain patches belonging to 2 distinct repos >>>>>> (e.g. xen and livepatch-build-tools)? >>>>> >>>>> I can see two ways: >>>>> >>>>> 1) One series per project and mention in the cover letter that >>>>> modifications are required in another project (with link/title). >>>>> 2) Combine all the patches in one series and tag them differently. >>>>> I.e >>>>> [XEN] [LIVEPATCH]. >>>>> >>>>> 1) is preferable if you have a lot of patches in each repo. 2) can be >>>>> handy if you have only a couple of patches for one repo. >>>> >>>> 1 is also easier for automated tools (like patchew) to deal with. >>> >>> Out of interest, in general developer will tend to cross-post those >>> patches. So in what way this would make it easier? >> >> If you have two separate series, then patchew will be able to handle one >> and not handle the other. If they're mixed in a single series, patchew >> won't be able to handle it at all. At the moment patchew doesn't do >> anything but give you a nice mbox / git branch to pull; but eventually >> the idea is that it will do some level of testing and give feedback >> (patch does/n't apply, patch does/n't build, patch does/n't pass smoke >> tests / &c). > > Oh, so patchew will try to apply the series. If it does not fully apply, > then it means the series does not target Xen, right? Either that, or the series needs to be rebased. I rather doubt the patchew authors have spent a lot of time trying to distinguish the two. :-) > I haven't used much patchew so far, but it looks like I should give a > try when committing/reviewing series :). Yes, I've found it quite useful. It automatically adds acks and r-b's as they're given, and also adds the message id into the commit message, which could be useful. One warning: Don't use patchew's branch if you think you might commit a series, because the "committer" is always listed as patchew, rather than yourself. You can see a couple of places in recent history where I've done this, not realizing; but I think it's something we want to avoid. Use the mbox to apply the series instead. -George
On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote: > Thanks Julien. I will do that next time (unless you guys want me to > re-send all this ;-)). > > BTW, I also pushed my changes onto the xenbits server: > http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary > http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary > > I hope that makes navigation and dealing with the swarm of patches a > bit easier. Please (re)send two patch series, one for Xen and one for build tools. Even for he subset you posted before, I can't figure out whether they're ok to push straight away, or need more review. This will be far easier to do in one single go (per repo). My workflow for series is something like this: First, confirm your git settings (details as appropriate) $ git config -l | grep sendemail sendemail.smtpserver= $SERVER sendemail.chainreplyto=false sendemail.to=Xen-devel <xen-devel@lists.xenproject.org> sendemail.from= $ME <$ME@example.com> Second, render the patch series: $ mkdir foo-v1 $ cd foo-v1 $ git format-patch master --cover-letter 0000-cover-letter.patch 0001- .... .... $ $EDITOR 0000-cover-letter.patch Fill in as appropriate. Provide a brief overview, note the subject of companion series, etc. I also include the union of all CC'd people in each patch just below the Subject: header which avoids having to manually specify them later. Be aware that it is strict about RFCs, so has to be Cc: and not CC: Third, double check everything: $ git send-email --dry-run *.patch Fourth, spam the list by dropping the --dry-run. Fifth, sit back and watch the reviews come in[1]. ~Andrew [1] Who am I kidding? This is invariably "pick up one of the other urgent tasks that you put to one side a little while ago..." ;)
> On 15 Aug 2019, at 17:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote: >> Thanks Julien. I will do that next time (unless you guys want me to >> re-send all this ;-)). >> >> BTW, I also pushed my changes onto the xenbits server: >> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary >> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary >> >> I hope that makes navigation and dealing with the swarm of patches a >> bit easier. > > Please (re)send two patch series, one for Xen and one for build tools. > Even for he subset you posted before, I can't figure out whether they're > ok to push straight away, or need more review. This will be far easier > to do in one single go (per repo). > > My workflow for series is something like this: > > First, confirm your git settings (details as appropriate) > > $ git config -l | grep sendemail > sendemail.smtpserver= $SERVER > sendemail.chainreplyto=false > sendemail.to=Xen-devel <xen-devel@lists.xenproject.org> > sendemail.from= $ME <$ME@example.com> > > Second, render the patch series: > > $ mkdir foo-v1 > $ cd foo-v1 > $ git format-patch master --cover-letter > 0000-cover-letter.patch > 0001- .... > .... > > $ $EDITOR 0000-cover-letter.patch > > Fill in as appropriate. Provide a brief overview, note the subject of > companion series, etc. I also include the union of all CC'd people in > each patch just below the Subject: header which avoids having to > manually specify them later. Be aware that it is strict about RFCs, so > has to be Cc: and not CC: > > Third, double check everything: > > $ git send-email --dry-run *.patch > > Fourth, spam the list by dropping the --dry-run. > > Fifth, sit back and watch the reviews come in[1]. > > ~Andrew @Andrew: You just outlined what's in the wiki and what the add_maintainers tool does. We should chat about the Cc: vs CC: * I may need to fix the tool as it uses CC: when used with some options @Pawel: I submitted https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01575.html <https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01575.html> https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01581.html <https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01581.html> which once applied ensures that the tools can be used on the live patch build tools I also added https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git> Lars
On 8/15/19 12:29 PM, Andrew Cooper wrote: > On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote: >> Thanks Julien. I will do that next time (unless you guys want me to >> re-send all this ;-)). >> >> BTW, I also pushed my changes onto the xenbits server: >> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary >> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary >> >> I hope that makes navigation and dealing with the swarm of patches a >> bit easier. > > Please (re)send two patch series, one for Xen and one for build tools. > Even for he subset you posted before, I can't figure out whether they're > ok to push straight away, or need more review. This will be far easier > to do in one single go (per repo). They look pretty good. Just need some extra test-cases. And I will need to update the ts-livepatch test-case to take advantage of them. >
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 725697c132..e0ebb586b6 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -2560,7 +2560,25 @@ int xc_livepatch_get(xc_interface *xch, xen_livepatch_status_t *status); /* - * The heart of this function is to get an array of xen_livepatch_status_t. + * Get a number of available payloads and get actual total size of + * the payloads' name array. + * + * This functions is typically executed first before the xc_livepatch_list() + * to obtain the sizes and correctly allocate all necessary data resources. + * + * The return value is zero if the hypercall completed successfully. + * + * If there was an error performing the sysctl operation, the return value + * will contain the hypercall error code value. + */ +int xc_livepatch_list_get_sizes(xc_interface *xch, unsigned int *nr, + uint64_t *name_total_size); + +/* + * The heart of this function is to get an array of the following objects: + * - xen_livepatch_status_t: states and return codes of payloads + * - name: names of payloads + * - len: lengths of corresponding payloads' names * * However it is complex because it has to deal with the hypervisor * returning some of the requested data or data being stale @@ -2571,21 +2589,20 @@ int xc_livepatch_get(xc_interface *xch, * 'left' are also updated with the number of entries filled out * and respectively the number of entries left to get from hypervisor. * - * It is expected that the caller of this function will take the - * 'left' and use the value for 'start'. This way we have an - * cursor in the array. Note that the 'info','name', and 'len' will - * be updated at the subsequent calls. + * It is expected that the caller of this function will first issue the + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names + * as well as the current number of payload entries. + * The total sizes are required and supplied via the 'name_total_size' + * parameter. * - * The 'max' is to be provided by the caller with the maximum - * number of entries that 'info', 'name', and 'len' arrays can - * be filled up with. - * - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE - * length. + * The 'max' is to be provided by the caller with the maximum number of + * entries that 'info', 'name', 'len' arrays can be filled up with. * * Each entry in the 'info' array is expected to be of xen_livepatch_status_t * structure size. * + * Each entry in the 'name' array may have an arbitrary size. + * * Each entry in the 'len' array is expected to be of uint32_t size. * * The return value is zero if the hypercall completed successfully. @@ -2597,10 +2614,12 @@ int xc_livepatch_get(xc_interface *xch, * will contain the number of entries that had been succesfully * retrieved (if any). */ -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, - xen_livepatch_status_t *info, char *name, - uint32_t *len, unsigned int *done, - unsigned int *left); +int xc_livepatch_list(xc_interface *xch, const unsigned int max, + const unsigned int start, + struct xen_livepatch_status *info, + char *name, uint32_t *len, + const uint64_t name_total_size, + unsigned int *done, unsigned int *left); /* * The operations are asynchronous and the hypervisor may take a while diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c index a8e9e7d1e2..d787f3f29f 100644 --- a/tools/libxc/xc_misc.c +++ b/tools/libxc/xc_misc.c @@ -662,7 +662,48 @@ int xc_livepatch_get(xc_interface *xch, } /* - * The heart of this function is to get an array of xen_livepatch_status_t. + * Get a number of available payloads and get actual total size of + * the payloads' name array. + * + * This functions is typically executed first before the xc_livepatch_list() + * to obtain the sizes and correctly allocate all necessary data resources. + * + * The return value is zero if the hypercall completed successfully. + * + * If there was an error performing the sysctl operation, the return value + * will contain the hypercall error code value. + */ +int xc_livepatch_list_get_sizes(xc_interface *xch, unsigned int *nr, + uint64_t *name_total_size) +{ + DECLARE_SYSCTL; + int rc; + + if ( !nr || !name_total_size ) + { + errno = EINVAL; + return -1; + } + + memset(&sysctl, 0, sizeof(sysctl)); + sysctl.cmd = XEN_SYSCTL_livepatch_op; + sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST; + + rc = do_sysctl(xch, &sysctl); + if ( rc ) + return rc; + + *nr = sysctl.u.livepatch.u.list.nr; + *name_total_size = sysctl.u.livepatch.u.list.name_total_size; + + return 0; +} + +/* + * The heart of this function is to get an array of the following objects: + * - xen_livepatch_status_t: states and return codes of payloads + * - name: names of payloads + * - len: lengths of corresponding payloads' names * * However it is complex because it has to deal with the hypervisor * returning some of the requested data or data being stale @@ -673,21 +714,20 @@ int xc_livepatch_get(xc_interface *xch, * 'left' are also updated with the number of entries filled out * and respectively the number of entries left to get from hypervisor. * - * It is expected that the caller of this function will take the - * 'left' and use the value for 'start'. This way we have an - * cursor in the array. Note that the 'info','name', and 'len' will - * be updated at the subsequent calls. + * It is expected that the caller of this function will first issue the + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names + * as well as the current number of payload entries. + * The total sizes are required and supplied via the 'name_total_size' + * parameter. * - * The 'max' is to be provided by the caller with the maximum - * number of entries that 'info', 'name', and 'len' arrays can - * be filled up with. - * - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE - * length. + * The 'max' is to be provided by the caller with the maximum number of + * entries that 'info', 'name', 'len' arrays can be filled up with. * * Each entry in the 'info' array is expected to be of xen_livepatch_status_t * structure size. * + * Each entry in the 'name' array may have an arbitrary size. + * * Each entry in the 'len' array is expected to be of uint32_t size. * * The return value is zero if the hypercall completed successfully. @@ -699,11 +739,12 @@ int xc_livepatch_get(xc_interface *xch, * will contain the number of entries that had been succesfully * retrieved (if any). */ -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, +int xc_livepatch_list(xc_interface *xch, const unsigned int max, + const unsigned int start, struct xen_livepatch_status *info, char *name, uint32_t *len, - unsigned int *done, - unsigned int *left) + const uint64_t name_total_size, + unsigned int *done, unsigned int *left) { int rc; DECLARE_SYSCTL; @@ -714,27 +755,33 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, uint32_t max_batch_sz, nr; uint32_t version = 0, retries = 0; uint32_t adjust = 0; - ssize_t sz; + off_t name_off = 0; + uint64_t name_sz; - if ( !max || !info || !name || !len ) + if ( !max || !info || !name || !len || !done || !left ) { errno = EINVAL; return -1; } + if ( name_total_size == 0 ) + { + errno = ENOENT; + return -1; + } + + memset(&sysctl, 0, sizeof(sysctl)); sysctl.cmd = XEN_SYSCTL_livepatch_op; sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST; - sysctl.u.livepatch.pad = 0; - sysctl.u.livepatch.u.list.version = 0; sysctl.u.livepatch.u.list.idx = start; - sysctl.u.livepatch.u.list.pad = 0; max_batch_sz = max; - /* Convience value. */ - sz = sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE; + name_sz = name_total_size; *done = 0; *left = 0; do { + uint64_t _name_sz; + /* * The first time we go in this loop our 'max' may be bigger * than what the hypervisor is comfortable with - hence the first @@ -754,11 +801,11 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, sysctl.u.livepatch.u.list.nr = nr; /* Fix the size (may vary between hypercalls). */ HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info)); - HYPERCALL_BOUNCE_SET_SIZE(name, nr * nr); + HYPERCALL_BOUNCE_SET_SIZE(name, name_sz); HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len)); /* Move the pointer to proper offset into 'info'. */ (HYPERCALL_BUFFER(info))->ubuf = info + *done; - (HYPERCALL_BUFFER(name))->ubuf = name + (sz * *done); + (HYPERCALL_BUFFER(name))->ubuf = name + name_off; (HYPERCALL_BUFFER(len))->ubuf = len + *done; /* Allocate memory. */ rc = xc_hypercall_bounce_pre(xch, info); @@ -827,14 +874,19 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start, break; } *left = sysctl.u.livepatch.u.list.nr; /* Total remaining count. */ + _name_sz = sysctl.u.livepatch.u.list.name_total_size; /* Total received name size. */ /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */ HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info))); - HYPERCALL_BOUNCE_SET_SIZE(name, (rc * sz)); + HYPERCALL_BOUNCE_SET_SIZE(name, _name_sz); HYPERCALL_BOUNCE_SET_SIZE(len, (rc * sizeof(*len))); /* Bounce the data and free the bounce buffer. */ xc_hypercall_bounce_post(xch, info); xc_hypercall_bounce_post(xch, name); xc_hypercall_bounce_post(xch, len); + + name_sz -= _name_sz; + name_off += _name_sz; + /* And update how many elements of info we have copied into. */ *done += rc; /* Update idx. */ diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c index a37b2457ff..8ac3d567fc 100644 --- a/tools/misc/xen-livepatch.c +++ b/tools/misc/xen-livepatch.c @@ -64,14 +64,14 @@ static const char *state2str(unsigned int state) return names[state]; } -/* This value was choosen adhoc. It could be 42 too. */ -#define MAX_LEN 11 static int list_func(int argc, char *argv[]) { - unsigned int idx, done, left, i; + unsigned int nr, done, left, i; xen_livepatch_status_t *info = NULL; char *name = NULL; uint32_t *len = NULL; + uint64_t name_total_size; + off_t name_off; int rc = ENOMEM; if ( argc ) @@ -79,65 +79,73 @@ static int list_func(int argc, char *argv[]) show_help(); return -1; } - idx = left = 0; - info = malloc(sizeof(*info) * MAX_LEN); - if ( !info ) - return rc; - name = malloc(sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE * MAX_LEN); - if ( !name ) + done = left = 0; + + rc = xc_livepatch_list_get_sizes(xch, &nr, &name_total_size); + if ( rc ) { - free(info); + rc = errno; + fprintf(stderr, "Failed to get list sizes.\n" + "Error %d: %s\n", + rc, strerror(rc)); return rc; } - len = malloc(sizeof(*len) * MAX_LEN); - if ( !len ) { - free(name); - free(info); + + if ( nr == 0 ) + { + fprintf(stdout, "Nothing to list\n"); + return 0; + } + + info = malloc(nr * sizeof(*info)); + if ( !info ) return rc; + + name = malloc(name_total_size * sizeof(*name)); + if ( !name ) + goto error_name; + + len = malloc(nr * sizeof(*len)); + if ( !len ) + goto error_len; + + memset(info, 'A', nr * sizeof(*info)); + memset(name, 'B', name_total_size * sizeof(*name)); + memset(len, 'C', nr * sizeof(*len)); + name_off = 0; + + rc = xc_livepatch_list(xch, nr, 0, info, name, len, name_total_size, &done, &left); + if ( rc || done != nr || left > 0) + { + rc = errno; + fprintf(stderr, "Failed to list %d/%d.\n" + "Error %d: %s\n", + left, nr, rc, strerror(rc)); + goto error; } - do { - done = 0; - /* The memset is done to catch errors. */ - memset(info, 'A', sizeof(*info) * MAX_LEN); - memset(name, 'B', sizeof(*name) * MAX_LEN * XEN_LIVEPATCH_NAME_SIZE); - memset(len, 'C', sizeof(*len) * MAX_LEN); - rc = xc_livepatch_list(xch, MAX_LEN, idx, info, name, len, &done, &left); - if ( rc ) - { - rc = errno; - fprintf(stderr, "Failed to list %d/%d.\n" - "Error %d: %s\n", - idx, left, rc, strerror(rc)); - break; - } - if ( !idx ) - fprintf(stdout," ID | status\n" - "----------------------------------------+------------\n"); + fprintf(stdout," ID | status\n" + "----------------------------------------+------------\n"); - for ( i = 0; i < done; i++ ) - { - unsigned int j; - uint32_t sz; - char *str; - - sz = len[i]; - str = name + (i * XEN_LIVEPATCH_NAME_SIZE); - for ( j = sz; j < XEN_LIVEPATCH_NAME_SIZE; j++ ) - str[j] = '\0'; - - printf("%-40s| %s", str, state2str(info[i].state)); - if ( info[i].rc ) - printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc)); - else - puts(""); - } - idx += done; - } while ( left ); + for ( i = 0; i < done; i++ ) + { + char *name_str = name + name_off; + + printf("%-40.*s| %s", len[i], name_str, state2str(info[i].state)); + if ( info[i].rc ) + printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc)); + else + puts(""); + + name_off += len[i]; + } +error: + free(len); +error_len: free(name); +error_name: free(info); - free(len); return rc; } #undef MAX_LEN diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index f88cf3bc73..f486cb3021 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -1163,7 +1163,6 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) if ( list->nr && (!guest_handle_okay(list->status, list->nr) || - !guest_handle_okay(list->name, XEN_LIVEPATCH_NAME_SIZE * list->nr) || !guest_handle_okay(list->len, list->nr)) ) return -EINVAL; @@ -1174,23 +1173,35 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) return -EINVAL; } + list->name_total_size = 0; if ( list->nr ) { + uint64_t name_offset = 0; + list_for_each_entry( data, &payload_list, list ) { - uint32_t len; + uint32_t name_len; if ( list->idx > i++ ) continue; status.state = data->state; status.rc = data->rc; - len = strlen(data->name) + 1; + + name_len = strlen(data->name) + 1; + list->name_total_size += name_len; + + if ( !guest_handle_subrange_okay(list->name, name_offset, + name_offset + name_len - 1) ) + { + rc = -EINVAL; + break; + } /* N.B. 'idx' != 'i'. */ - if ( __copy_to_guest_offset(list->name, idx * XEN_LIVEPATCH_NAME_SIZE, - data->name, len) || - __copy_to_guest_offset(list->len, idx, &len, 1) || + if ( __copy_to_guest_offset(list->name, name_offset, + data->name, name_len) || + __copy_to_guest_offset(list->len, idx, &name_len, 1) || __copy_to_guest_offset(list->status, idx, &status, 1) ) { rc = -EFAULT; @@ -1198,11 +1209,19 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list) } idx++; + name_offset += name_len; if ( (idx >= list->nr) || hypercall_preempt_check() ) break; } } + else + { + list_for_each_entry( data, &payload_list, list ) + { + list->name_total_size += strlen(data->name) + 1; + } + } list->nr = payload_cnt - i; /* Remaining amount. */ list->version = payload_version; spin_unlock(&payload_lock); diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index 335e193712..b86804b7a6 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -926,10 +926,11 @@ struct xen_sysctl_livepatch_get { * * If the hypercall returns an positive number, it is the number (up to `nr`) * of the payloads returned, along with `nr` updated with the number of remaining - * payloads, `version` updated (it may be the same across hypercalls. If it - * varies the data is stale and further calls could fail). The `status`, - * `name`, and `len`' are updated at their designed index value (`idx`) with - * the returned value of data. + * payloads, `version` updated (it may be the same across hypercalls. If it varies + * the data is stale and further calls could fail) and the name_total_size + * containing total size of transfered data for the array. + * The `status`, `name`, `len` are updated at their designed index value (`idx`) + * with the returned value of data. * * If the hypercall returns E2BIG the `nr` is too big and should be * lowered. The upper limit of `nr` is left to the implemention. @@ -952,11 +953,13 @@ struct xen_sysctl_livepatch_list { amount of payloads and version. OUT: How many payloads left. */ uint32_t pad; /* IN: Must be zero. */ + uint64_t name_total_size; /* OUT: Total size of all transfer names */ XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status; /* OUT. Must have enough space allocate for nr of them. */ XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each member - MUST XEN_LIVEPATCH_NAME_SIZE in size. - Must have nr of them. */ + may have an arbitrary length up to + XEN_LIVEPATCH_NAME_SIZE bytes. Must have + nr of them. */ XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's. Must have nr of them. */ };