After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755170 - NM never receives external DHCP client helper information with DHCPv4+IPv6 manual
NM never receives external DHCP client helper information with DHCPv4+IPv6 ma...
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-09-17 16:54 UTC by Dan Williams
Modified: 2015-10-03 07:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH] bus-manager: fix race condition in handling of incoming signals (1.69 KB, patch)
2015-09-28 08:36 UTC, Beniamino Galvani
none Details | Review
[PATCH v2] bus-manager: fix handling of incoming signals (3.38 KB, patch)
2015-09-30 14:42 UTC, Beniamino Galvani
none Details | Review

Description Dan Williams 2015-09-17 16:54:00 UTC
With git master as of 2015-09-17, if you have DHCPv4 configured with dhclient and IPv6 manual, NM never receives the response from the DHCP client helper.  NM does see the private socket being opened and then closed and new_connection_cb() is run, but nm-dhcp-listener.c::handle_event() is never run.

Possibly something due to the GDBus conversion and the recent bus-manager changes?  Since this is a private socket and everything is run synchronously we should be able to subscribe to the signal before its sent and thus receive it, but I'm not sure why things aren't happening.

NetworkManager[24494]: <debug> [1442505884.783379] [nm-bus-manager.c:213] private_server_new_connection(): (dhcp) accepted connection 0xf8c4a0 on private socket.
<printf debugging indicates new_connection_cb() gets run here>
<but no handle_event() gets run>
NetworkManager[24494]: <debug> [1442505884.790540] [nm-bus-manager.c:179] private_server_closed(): (dhcp) closed connection 0xf8c4a0 on private socket.
Comment 1 Beniamino Galvani 2015-09-28 08:36:40 UTC
Created attachment 312269 [details] [review]
[PATCH] bus-manager: fix race condition in handling of incoming signals

The attached patch apparently fixes the problem; even after some time spent debugging GDBusConnection and GDBusServer I'm still not sure if this is the right approach, though.
Comment 2 Thomas Haller 2015-09-29 15:21:36 UTC
(In reply to Beniamino Galvani from comment #1)
> Created attachment 312269 [details] [review] [review]
> [PATCH] bus-manager: fix race condition in handling of incoming signals
> 
> The attached patch apparently fixes the problem; even after some time spent
> debugging GDBusConnection and GDBusServer I'm still not sure if this is the
> right approach, though.

doesn't this run private_server_new_connection() on a separate thread?

I think that cause a multi-threadding issue... few code is actually thread-safe, and you cannot do this arbitrarily.
Comment 3 Beniamino Galvani 2015-09-30 14:42:30 UTC
Created attachment 312434 [details] [review]
[PATCH v2] bus-manager: fix handling of incoming signals

(In reply to Thomas Haller from comment #2)
> doesn't this run private_server_new_connection() on a separate thread?
> 
> I think that cause a multi-threadding issue... few code is actually
> thread-safe, and you cannot do this arbitrarily.

Yeah, that's right. In any case, I suspect this is a bug in GDBusServer which schedules the closed callback before deliverying signals. New patch attached.
Comment 4 Thomas Haller 2015-09-30 15:18:54 UTC
(In reply to Beniamino Galvani from comment #3)
> Created attachment 312434 [details] [review] [review]
> [PATCH v2] bus-manager: fix handling of incoming signals
> 
> (In reply to Thomas Haller from comment #2)
> > doesn't this run private_server_new_connection() on a separate thread?
> > 
> > I think that cause a multi-threadding issue... few code is actually
> > thread-safe, and you cannot do this arbitrarily.
> 
> Yeah, that's right. In any case, I suspect this is a bug in GDBusServer
> which schedules the closed callback before deliverying signals. New patch
> attached.

I'd use g_slice_new().

Otherwise LGTM
Comment 5 Dan Williams 2015-10-03 01:08:27 UTC
LGTM
Comment 6 Beniamino Galvani 2015-10-03 07:54:39 UTC
(In reply to Thomas Haller from comment #4)
> I'd use g_slice_new().

Fixed and applied to master:

7c5518ac8d8c bus-manager: fix handling of incoming signals