All callers of _nm_setting_get_private() got the offset from the
property info. Add a wrapper _nm_setting_get_private_field() that
takes the property info. This way, it can add some assertions.
Preferably, we embed the private struct in the GObject struct itself.
In the past, we didn't do that, because the struct was in public headers
and changing that would have been an ABI break. For those struct, we
still use g_type_class_add_private().
We have some structs, where the private struct is embedded. An
alternative to that would be, to not have the private struct at all,
like done for NMSettingOvsBridge.
Anyway. So for direct properties we need to capture the offset of the
field (in the private struct). We can either set the offset of the
private struct in _nm_setting_class_commit() to zero and let the field
offset include the private structure offset. Or, the offset of the
private struct is accounted during _nm_setting_class_commit().
Both approaches are basically the same. Just do it consistently. For no
particular reason, choose to set the offset of the private data to zero
for those types.
Several properties like "connection.type" are enum-like and only take a few
known values. We can use a NMRefString to share their instances.
Currently nm_setting_duplicate() does not yet explicitly handle direct properties.
But it should, because it can handle them more efficiently. If it would do that, it
would be very cheap to "copy" a NMRefString. But even with the current implementation
will the result be deduplicated.
"wireguard.private-key" is special, because the setter does some unusual
normalization. To implement that, we need to use "direct_hook.set_string_func".
We want that our properties have little special cases and follow a
few common behaviors. For example, we have string properties, and those
should mostly behave the same (e.g. by being "direct-string"
properties).
That is already not fully enough, because we have slightly different
behaviors. For example, we have string properties that should have their
whitespace stripped, that should be ascii case down converted, that
should be normalized IP or MAC addresses. So far, that was expressed via
simple fields in NMSettInfoProperty, like NMSettInfoProperty's
direct_set_string_ascii_strdown field.
But that is not enough. In particular, for "wireguard.private-key" we
perform a different kind of normalization (base64 parsing, and taking
care not to leak secret in memory). It seems to special to add a boolean
flag "direct_set_string_wireguard_private_key".
Instead, add a hook that can cover that.
We need a hook, because we want one setter implementation throughout. Commonly,
we have at least two setters: the GObject set_property() and from D-Bus.
Both should call into the same underlying implementation, to avoid code
duplication. For that, the tweaked behavior must be "down", that is at
the deepest point in the call stack where we set the string. That's why
we need the hook. The alternative would be two special implementation
for GObject and D-Bus setters (and in the future we might add setters
from keyfile).
Both callers themselves needed to call _nm_setting_get_private(),
only to pass it to _property_direct_set_string().
Instead, pass the necessary parameters to _property_direct_set_string(),
so it can do that itself.
This additional parameters will be necessary when we add a hook for
setting the string.
We cache the virtual-iface-name. The caching is also part of the API as
nm_setting_infiniband_get_virtual_interface_name() returns a const
string.
As the value is computed and based on the parent and the p-key, we must
clear the cache when the parent or p-key changes (or detect that it's
invalid).
Previously, we were simply clearing the value in the set_property() function,
which is the only setter of these two properties. If we make these
properties "direct properties", then they will be directly set via
from_dbus_fcn() which bypasses the GObject setter. Which is a problem
for the cache invalidation.
We could either not make those properties direct properties. The problem
is that direct properties are nice, and they will in the future
implement further optimizations for them. Also, they are the default
implementation, and it seems clearer to build something on top of that,
instead of deviating from the default.
Instead, let the caching detect when the value needs to be regenerated.
This seems a questionable thing to do, and should be made clearer by
having a parameter (that makes you think about what is happening here).
Also, the normalization for vxlan.remote does not perform this mapping,
so the parameter is there so that the approach can handle both flavors.
Let's sprinkle some snake ointment.
This is questionable, because we copy secrets all over the place where
we their deallocation (and clearing) is not in our control. For example,
the GValue setter/getter copies the string (but does not clean the
secret). Also, when converting the property to a GVariant, we won't
clear it. So this does not catch a lot of cases.
Still, if we can with relative ease avoid leaking the string at some
places, do it.
libnm's data structures are commonly not thread safe (like
NMConnection). However, it must be possible that all operations can
operate on *different* data in a thread safe manner. That means, we need
to take care about our global variables.
nm_utils_ssid_to_utf8() uses a list of encodings, which gets cached.
- replace the GHashTables with a static list. Since it doesn't cost
anything, make the list sorted and look it up via binary search.
nm_hash_str() has the proper name and signature for that it does.
That is, it has a "nm_hash_*" prefix and the parameter is of type
"const char *".
nm_hash_str() has this name because it is primarily about hashing.
For hash tables, glib has g_str_hash() and g_str_equal(). We want
to replace g_str_hash() with our implementation (nm_hash_str()) because
that uses siphash24 with a random seed.
But in those cases we want to use the more familiar name "nm_str_hash()",
which reminds of g_str_hash() and follows the pattern of g_str_equal().
Thus:
g_hash_table_new(nm_str_hash, g_str_equal);
is preferable over
g_hash_table_new(nm_hash_str, g_str_equal);
Hence, we have (and had) nm_str_hash() effectively an alias to
nm_hash_str.
The question is: which name is preferable? Or should they be both present
for their slightly distinct uses? The approach taken here is to have
both names, to reflect their purpose better.
But as the usage of nm_str_hash is as function pointer for GHashTable, it was
not an inline function and we'd pay a small overhead with this approach of
aliasing. Avoid that overhead by defining nm_str_hash with the C
preprocessor.
For similar reasons, do that for nm_direct_hash.
The force-commit flag is used to force the commit of an address or a
route from DHCP/RA even when it was removed from platform externally
(for example because it expired). Routes generated from the l3cd
should also have the flag set.
Without this, NM properly re-adds the DHCP address after the lease is
lost and obtained again, but fails to add the prefix-route.
Fixes: 2838b1c5e8 ('core: track force-commit flag for l3cd and platform objects')
https://bugzilla.redhat.com/show_bug.cgi?id=2033991https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1049
Consider externally removed IPv4LL bad, proceed as if a collision was
detected. Otherwise we trip an assert:
<trace> [1641816260.3963] l3cfg[b8bf8cd16ec4732e,ifindex=47]: emit signal (platform-change-on-idle, obj-type-flags=0x14)
**
nm:ERROR:src/core/nm-l3-ipv4ll.c:888:_ipv4ll_state_change: code should not be reached
Aborted (core dumped)
#3 0x00007f41621d020e in g_assertion_message_expr (domain=domain@entry=0x5559cd829140 "nm",
file=file@entry=0x5559cd823e51 "src/core/nm-l3-ipv4ll.c",
line=line@entry=888, func=func@entry=0x5559cd824d30 <__func__.38810> "_ipv4ll_state_change",
expr=expr@entry=0x0) at gtestutils.c:2556
#4 0x00005559cd719686 in _ipv4ll_state_change (self=0x5559cef886c0,
is_on_idle_handler=0) at src/core/nm-l3-ipv4ll.c:888
#8 0x00007f41626a5093 in <emit signal ??? on instance 0x5559ceffaa30 [NML3Cfg]>
(instance=instance@entry=0x5559ceffaa30, signal_id=<optimized out>,
detail=detail@entry=0) at gsignal.c:3448
#9 0x00005559cd511a03 in _nm_l3cfg_emit_signal_notify
(self=self@entry=0x5559ceffaa30 [NML3Cfg], notify_data=notify_data@entry=0x7ffd1caa8640)
at src/core/nm-l3cfg.c:576
#10 0x00005559cd5122dc in _nm_l3cfg_emit_signal_notify_acd_event (self=0x5559ceffaa30 [NML3Cfg],
acd_data=<optimized out>) at src/core/nm-l3cfg.c:2008
#11 0x00005559cd512463 in _nm_l3cfg_emit_signal_notify_acd_event_all
(self=0x5559ceffaa30 [NML3Cfg]) at src/core/nm-l3cfg.c:2041
#12 0x00005559cd5194ef in _l3_acd_nacd_event (fd=<optimized out>, condition=<optimized out>,
user_data=<optimized out>) at src/core/nm-l3cfg.c:1536
#13 0x00007f41621a895d in g_main_dispatch (context=0x5559ceec8bc0) at gmain.c:3193
#14 0x00007f41621a895d in g_main_context_dispatch (context=context@entry=0x5559ceec8bc0)
at gmain.c:3873
#15 0x00007f41621a8d18 in g_main_context_iterate (context=0x5559ceec8bc0, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3946
#16 0x00007f41621a9042 in g_main_loop_run (loop=0x5559ceea40f0) at gmain.c:4142
#17 0x00005559cd47c7a4 in main (argc=<optimized out>, argv=<optimized out>)
at src/core/main.c:511
https://bugzilla.redhat.com/show_bug.cgi?id=2028404https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1059
Try to debug a hang in platform code, presumably during poll().
This logging seems useful for debugging this particular issue,
but it might be useful in general.
