search for: nr_handl

...ons.c +++ b/src/connections.c @@ -69,10 +69,12 @@ struct connection { pthread_mutex_t write_lock; pthread_mutex_t status_lock; int status; /* 1 for more I/O with client, 0 for shutdown, -1 on error */ - void *handle; void *crypto_session; int nworkers; + void **handles; + size_t nr_handles; + uint64_t exportsize; int readonly; int can_flush; @@ -100,16 +102,37 @@ static void raw_close (struct connection *); /* Accessors for public fields in the connection structure. * Everything else is private to this file. */ -void -connection_set_handle (struct connection *conn, vo...

...ions.c +++ b/src/connections.c @@ -69,10 +69,12 @@ struct connection { pthread_mutex_t write_lock; pthread_mutex_t status_lock; int status; /* 1 for more I/O with client, 0 for shutdown, -1 on error */ - void *handle; void *crypto_session; int nworkers; + void **handles; + size_t nr_handles; + uint64_t exportsize; int readonly; int can_flush; @@ -100,16 +102,37 @@ static void raw_close (struct connection *); /* Accessors for public fields in the connection structure. * Everything else is private to this file. */ -void -connection_set_handle (struct connection *conn, vo...

...h crashes; In that case the following for(;;) structure will never have a MAC match, then the BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" to avoid de-referencing an undefined pointer (sbp->CreateChild) in the next code line. ... for (i = 0; i < nr_handles; i++) { DevicePath = DevicePathFromHandle(handles[i]); if (efi_get_MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { sb_handle = handles[i]; status = uefi_call_wrapper(BS->OpenProtocol, 6, sb_handle, bguid, (void **)&a...

...I_SERVICE_BINDINGs are for networking */ > struct efi_binding *efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) > { > EFI_SERVICE_BINDING *sbp; > struct efi_binding *b; > EFI_STATUS status; > - EFI_HANDLE protocol, child, *handles = NULL; > - UINTN i, nr_handles = 0; > + EFI_HANDLE protocol, child; > > b = malloc(sizeof(*b)); > if (!b) > return NULL; > > - status = LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles); > + status = uefi_call_wrapper(BS->OpenProtocol, 6, pxe_handle, &...

...ING *sbp; > +EFI_SERVICE_BINDING *sbp =NULL; > ... > > -? ? if (status != EFI_SUCCESS) > +? ? if (status != EFI_SUCCESS || sbp == NULL) >? ? ? ? goto free_binding; > ... The presumption was that we'd see an error rather than non-error from LibLocateHandle() when nr_handles is 0 and be guaranteed to find a matching handle.? Your additional measures seem the best choice. -- -Gene <<< OK I have adopted this code approach; testing it since last week, so far so good. Presumably there are other people testing this; feedback appreciated. Best, Patrick

...b/drivers/xen/xenbus/xenbus_client.c @@ -53,14 +53,16 @@ struct xenbus_map_node { struct vm_struct *area; /* PV */ struct page *page; /* HVM */ }; - grant_handle_t handle; + grant_handle_t handle[XENBUS_MAX_RING_PAGES]; + unsigned int nr_handles; }; static DEFINE_SPINLOCK(xenbus_valloc_lock); static LIST_HEAD(xenbus_valloc_pages); struct xenbus_ring_ops { - int (*map)(struct xenbus_device *dev, int gnt, void **vaddr); + int (*map)(struct xenbus_device *dev, int gnt[], int nr_gnts, + void **vaddr);...

...b/drivers/xen/xenbus/xenbus_client.c @@ -53,14 +53,16 @@ struct xenbus_map_node { struct vm_struct *area; /* PV */ struct page *page; /* HVM */ }; - grant_handle_t handle; + grant_handle_t handle[XENBUS_MAX_RING_PAGES]; + unsigned int nr_handles; }; static DEFINE_SPINLOCK(xenbus_valloc_lock); static LIST_HEAD(xenbus_valloc_pages); struct xenbus_ring_ops { - int (*map)(struct xenbus_device *dev, int gnt, void **vaddr); + int (*map)(struct xenbus_device *dev, int gnt[], int nr_gnts, + void **vaddr);...

...b/drivers/xen/xenbus/xenbus_client.c @@ -53,14 +53,16 @@ struct xenbus_map_node { struct vm_struct *area; /* PV */ struct page *page; /* HVM */ }; - grant_handle_t handle; + grant_handle_t handle[XENBUS_MAX_RING_PAGES]; + unsigned int nr_handles; }; static DEFINE_SPINLOCK(xenbus_valloc_lock); static LIST_HEAD(xenbus_valloc_pages); struct xenbus_ring_ops { - int (*map)(struct xenbus_device *dev, int gnt, void **vaddr); + int (*map)(struct xenbus_device *dev, int gnt[], int nr_gnts, + void **vaddr);...

...gt; > - if (status != EFI_SUCCESS) >> > + if (status != EFI_SUCCESS || sbp == >> NULL) >> > goto free_binding; >> > ... >> >> The presumption was that we'd see an error rather than >> non-error from LibLocateHandle() when nr_handles is 0 and be guaranteed >> to find a >> matching handle. Your additional measures seem the best choice. >> -- >> -Gene >> <<< >> >> OK I have adopted this code approach; testing it since last >> week, so far so good. >> Presumably...

...the following for(;;) structure will never have a MAC match, then the > BS->OpenProtocol will never fail returning the needed "status != EFI_SUCCESS" > to avoid de-referencing an undefined pointer (sbp->CreateChild) in the next code line. > > ... > for (i = 0; i < nr_handles; i++) { > DevicePath = DevicePathFromHandle(handles[i]); > if (efi_get_MAC(DevicePath, &mac_2, PXE_MAC_LENGTH) > && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { > sb_handle = handles[i]; > stat...

...files changed, 18 insertions(+), 2 deletions(-) diff --git a/server/connections.c b/server/connections.c index 819f7b8..ec28815 100644 --- a/server/connections.c +++ b/server/connections.c @@ -269,9 +269,8 @@ new_connection (int sockin, int sockout, int nworkers) goto error; } conn->nr_handles = backend->i + 1; - memset (conn->handles, -1, conn->nr_handles * sizeof *conn->handles); for_each_backend (b) - conn->handles[b->i].handle = NULL; + reset_b_conn_handle (&conn->handles[b->i]); conn->status = 1; conn->nworkers = nworkers; diff -...

...(struct b_conn_handle *h) +reset_handle (struct handle *h) { h->handle = NULL; h->state = 0; @@ -222,7 +230,7 @@ struct connection { void *crypto_session; int nworkers; - struct b_conn_handle *handles; + struct handle *handles; /* One per plugin and filter. */ size_t nr_handles; char exportname[NBD_MAX_STRING + 1]; @@ -239,6 +247,12 @@ struct connection { connection_close_function close; }; +static inline struct handle * +get_handle (struct connection *conn, int i) +{ + return &conn->handles[i]; +} + extern void handle_single_connection (int sockin,...

From: Sylvain Gault <sylvain.gault at gmail.com> I don't know if I should merge those trivial warning fix into one commit. I can reformat it as requested. Those are a few warning fixes for the efi part. The code involved has mainly been introduced in recent commits. Sylvain Gault (3): efi: fix warnings about argument types efi: fix pointer-type mismatch assigment warning efi: fix

...andles _should_ be the same... -- -Gene <<< OK now it works. Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) what gives me all the handles that include the Service Binding Protocol "bguid". For each of this handles I get the DevPath handle and I parse it looking for the matching MAC address. The bguid handle with the right MAC is used for binding. So far it works in the problem...

...linux.e64, and immediately gives up. I have traced the problem to: /syslinux-6.03/efi/udp.c\core_udp_open() /syslinux-6.03/efi/main.c\efi_create_binding(&Udp4ServiceBindingProtocol, &Udp4Protocol); /syslinux-6.03/gnu-efi/gnu-efi-3.0/lib/hand.c\LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles); When LibLocateHandle() try to locate EFI_UDP4_SERVICE_BINDING_PROTOCOL it fails with EFI_NOT_FOUND (14) which looks like an HP firmware issue. Newer versions of the HP Elitebook family like 2570p and 8470p PXE boot syslinux.efi correctly. Unfortunately this error does not displa...

...ver/internal.h +++ b/server/internal.h @@ -151,7 +151,7 @@ typedef void (*connection_close_function) (struct connection *) struct b_conn_handle { void *handle; - // TODO add per-backend caching + uint64_t exportsize; }; struct connection { @@ -168,7 +168,6 @@ struct connection { size_t nr_handles; uint32_t cflags; - uint64_t exportsize; uint16_t eflags; bool readonly; bool can_flush; diff --git a/server/backend.c b/server/backend.c index b2054aa2..374d8540 100644 --- a/server/backend.c +++ b/server/backend.c @@ -132,10 +132,13 @@ backend_set_handle (struct backend *b, struct...

The previous incomplete patch was here: https://www.redhat.com/archives/libguestfs/2019-September/msg00049.html based on earlier discussion here: https://www.redhat.com/archives/libguestfs/2019-September/msg00047.html In v2: - The previous patch was incomplete. This version completes it by adding tests and extending nbdkit-sh-plugin. - nbdkit_export_name now returns NULL for error,

I'm fairly sure that these bugs which appear in the Python plugin: https://bugzilla.redhat.com/show_bug.cgi?id=1566516 https://bugzilla.redhat.com/show_bug.cgi?id=1566522 are really bugs in the SERIALIZE_ALL_REQUESTS thread model. See the first patch for the full explanation. The second patch is a fix for a race condition which is probably nudged into being by the first patch. Now this

...- > -Gene > <<< > > OK now it works. > Everything is done within efi_create_binding(EFI_GUID *bguid, EFI_GUID *pguid) > from image_DeviceHandle I get the right DevPath handle, I parse it and I get the MAC address. > Next I LibLocateHandle(ByProtocol, bguid, NULL, &nr_handles, &handles) > what gives me all the handles that include the Service Binding Protocol "bguid". > For each of this handles I get the DevPath handle and I parse it looking for the matching MAC address. > The bguid handle with the right MAC is used for binding. > > So far...

...> > ... > > > > - if (status != EFI_SUCCESS) > > + if (status != EFI_SUCCESS || sbp == > NULL) > > goto free_binding; > > ... > > The presumption was that we'd see an error rather than > non-error from LibLocateHandle() when nr_handles is 0 and be guaranteed to find a > matching handle. Your additional measures seem the best choice. > -- > -Gene > <<< > > OK I have adopted this code approach; testing it since last > week, so far so good. > Presumably there are other people testing this; feed...