Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
aboutsummaryrefslogtreecommitdiff
Commit message (Expand)AuthorAgeFilesLines
* udev-event: do not read stdout or stderr if the pipefd is not created•••Fixes #11255. HEADmasterYu Watanabe2018-12-281-6/+10
* switch-root: fix error message•••Fixes #11261. Yu Watanabe2018-12-281-1/+1
* core: free lines after reading them•••Closes https://github.com/systemd/systemd/issues/11251. Evgeny Vereshchagin2018-12-281-1/+1
* Do not start server if it is already runnning (#11245)rogerjames992018-12-281-7/+8
* meson: use cross compilation compatible c++ checkJames Hilliard2018-12-283-6/+3
* core: support %j in unit dependency resolution•••Commit 250e9fadbcc0ca90e697d7efb40855b054ed3b8f introduced support for %j/%J specifier in unit files. The function unit_name_printf is used in unit dependency resolution, such as Wants / After directives, but was missing support for the %j. Add to allow directives such as: [Unit] Wants=bar-%j.target Fixes: systemd/systemd#11217 Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Patrick Williams2018-12-223-0/+78
* NEWS: add one more name and adjust locationv240Zbigniew Jędrzejewski-Szmek2018-12-211-37/+37
* Merge pull request #11239 from poettering/news-v240-final•••NEWS and build system bump for 240Zbigniew Jędrzejewski-Szmek2018-12-212-32/+33
|\
| * NEWS: prepare for v240Lennart Poettering2018-12-211-29/+30
| * build-sys: bump package/library versionsLennart Poettering2018-12-211-3/+3
* | tree-wide: use assert_se() for signal operations with constants•••Continuation of a3ebe5eb620e49f0d24082876cafc7579261e64f: in other places we sometimes use assert_se(), and sometimes normal error handling. sigfillset and sigaddset can only fail if mask is NULL (which cannot happen if we are passing in a reference), or if the signal number is invalid (which really shouldn't happen when we are using a constant like SIGCHLD. If SIGCHLD is invalid, we have a bigger problem). So let's simplify things and always use assert_se() in those cases. In sigset_add_many() we could conceivably pass an invalid signal, so let's keep normal error handling here. The caller can do assert_se() around the sigprocmask_many() call if appropriate. '>= 0' is used for consistency with the rest of the codebase. Zbigniew Jędrzejewski-Szmek2018-12-214-19/+6
* | Merge pull request #11206 from cdown/cgroup_no_v1•••cgroup: Imply systemd.unified_cgroup_hierarchy=1 on cgroup_no_v1=allZbigniew Jędrzejewski-Szmek2018-12-213-3/+27
|\ \
| * | cgroup: Add NEWS entry for cgroup_no_v1=all implying unified usageChris Down2018-12-211-0/+4
| * | cgroup: Imply systemd.unified_cgroup_hierarchy=1 on cgroup_no_v1=all•••cgroup_no_v1=all doesn't make a whole lot of sense with legacy hierarchy (where we use v1 hierarchy for everything), or hybrid hierarchy (where we still use v1 hierarchy for resource control). Right now we have to tell people to add both cgroup_no_v1=all and systemd.unified_cgroup_hierarchy=1 to get the desired behaviour, however in reality it's hard to imagine any situation where someone passes cgroup_no_v1=all but *doesn't* want to use the unified cgroup hierarchy. Make it so that cgroup_no_v1=all produces intuitive behaviour in systemd by default, although it can still be disabled by passing systemd.unified_cgroup_hierarchy=0 explicitly. Chris Down2018-12-212-3/+23
* | | sd-device: ignore bind/unbind events for now•••Until systemd/udev are ready for the new events and do not flush entire device state on each new event received, we should ignore them. Dmitry Torokhov2018-12-211-0/+9
* | | Revert "sleep: offer hibernation only if the kernel image still exists"•••This reverts commit edda44605f06a41fb86b7ab8128dcf99161d2344. The kernel explicitly supports resuming with a different kernel than the one used before hibernation. If this is something that shouldn't be supported, the place to change this is in the kernel. We shouldn't censor something that this exclusively in the kernel's domain. People might be using this to switch kernels without restaring programs, and we'd break this functionality for them. Also, even if resuming with a different kernel was a bad idea, we don't really prevent that with this check, since most users have more than one kernel and can freely pick a different one from the menu. So this only affected the corner case where the kernel has been removed, but there is no reason to single it out. Zbigniew Jędrzejewski-Szmek2018-12-213-83/+6
* | | Merge pull request #11050 from poettering/resolved-domain-route•••resolved: beef up domain routingLennart Poettering2018-12-2123-116/+470
|\ \ \
| * | | man: document new systemd-resolved.service(8) routing features in more detailLennart Poettering2018-12-211-7/+36
| * | | man: split long section in systemd-resolved.service man page into three•••Also, do some minor updating. Lennart Poettering2018-12-211-4/+15
| * | | resolved: read DNS default route option from networkdLennart Poettering2018-12-211-0/+25
| * | | sd-network: add new API sd_network_link_get_dns_default_route()•••This simply reads from networkd's state files whether a link shall be used as DNS default route. Lennart Poettering2018-12-212-0/+22
| * | | networkd: permit DNS "DefaultRoute" configuration in .network filesLennart Poettering2018-12-216-4/+22
| * | | networkd: small simplificationLennart Poettering2018-12-211-8/+4
| * | | resolvectl: add support for reading/writing per-link 'default-route' booleanLennart Poettering2018-12-212-10/+75
| * | | resolvectl: minor whitespace fixLennart Poettering2018-12-211-1/+1
| * | | resolved: add bus API to set per-link "default route" booleanLennart Poettering2018-12-213-0/+58
| * | | resolved: add an explicit way to configure whether a link is useful as defaul...•••Previously, we'd use a link as "default" route depending on whether there are route-only domains defined on it or not. (If there are, it would not be used as default route, if there aren't it would.) Let's make this explicit and add a link variable controlling this. The variable is not changeable from the outside yet, but subsequent commits are supposed to add that. Note that making this configurable adds a certain amount of redundancy, as there are now two ways to ensure a link does not receive "default" lookup (i.e. DNS queries matching no configured route): 1. By ensuring that at least one other link configures a route on it (for example by add "." to its search list) 2. By setting this new boolean to false. But this is exactly what is intended with this patch: that there is an explicit way to configure on the link itself whether it receives 'default' traffic, rather than require this to be configured on other links. The variable added is a tri-state: if true, the link is suitable for recieving "default" traffic. If false, the link is not suitable for it. If unset (i.e. negative) the original logic of "has this route-only routes" is used, to ensure compatibility with the status quo ante. Lennart Poettering2018-12-215-23/+66
| * | | resolved: rework dns_server_limited_domains(), replace by dns_scope_has_route...•••The function dns_server_limited_domains() was very strange as it enumerate the domains associated with a DnsScope object to determine whether any "route-only" domains, but did so as a function associated with a DnsServer object. Let's clear this up, and replace it by a function associated with a DnsScope instead. This makes more sense philosphically and allows us to reduce the loops through which we need to jump to determine whether a scope is suitable for default routing a bit. Lennart Poettering2018-12-215-34/+51
| * | | resolved: bind .local domains to mDNS with DNS_SCOPE_YES, similar LLMNR•••Previously, we'd return DNS_SCOPE_MAYBE for all domain lookups matching LLMNR or mDNS. Let's upgrade this to DNS_SCOPE_YES, to make the binding stronger. The effect of this is that even if "local" is defined as routing domain on some iface, we'll still lookup domains in local via mDNS — if mDNS is turned on. This should not be limiting, as people who don't want such lookups should turn off mDNS altogether, as it is useless if nothing is routed to it. This also has the nice benefit that mDNS/LLMR continue to work if people use "~." as routing domain on some interface. Similar for LLMNR and single label names. Similar also for the link local IPv4 and IPv6 reverse lookups. Fixes: #10125 Lennart Poettering2018-12-212-9/+47
| * | | resolved: rework how we determine which scope to send a query to•••Fixes: #10830 #9825 #9472 Lennart Poettering2018-12-213-20/+47
| * | | resolved: add comment, explaining when Scope variables are copied from LinkLennart Poettering2018-12-211-0/+2
| * | | resolved: rename_DNS_SCOPE_INVALID → _DNS_SCOPE_MATCH_INVALID•••The _INVALID and _MAX enum fields should always use the full name of thenum. Lennart Poettering2018-12-211-1/+1
| * | | resolved: check dns_over_tls_mode in link_needs_save()•••This was forgotten when DoT was added. Lennart Poettering2018-12-211-1/+2
| * | | resolved: use structured initialization for DnsScopeLennart Poettering2018-12-211-6/+8
| | |/ | |/|
* | | Merge pull request #11210 from thom311/dhcp-set-client-id-no-inval•••dhcp: don't enforce hardware address length for sd_dhcp_client_set_client_id()Lennart Poettering2018-12-214-22/+27
|\ \ \
| * | | dhcp6: don't enforce DUID content for sd_dhcp6_client_set_duid()•••There are various functions to set the DUID of a DHCPv6 client. However, none of them allows to set arbitrary data. The closest is sd_dhcp6_client_set_duid(), which would still do validation of the DUID's content via dhcp_validate_duid_len(). Relax the validation and only log a debug message if the DUID does not validate. Note that dhcp_validate_duid_len() already is not very strict. For example with DUID_TYPE_LLT it only ensures that the length is suitable to contain hwtype and time. It does not further check that the length of hwaddr is non-zero or suitable for hwtype. Also, non-well-known DUID types are accepted for extensibility. Why reject certain DUIDs but allowing clearly wrong formats otherwise? The validation and failure should happen earlier, when accepting the unsuitable DUID. At that point, there is more context of what is wrong, and a better failure reason (or warning) can be reported to the user. Rejecting the DUID when setting up the DHCPv6 client seems not optimal, in particular because the DHCPv6 client does not care about actual content of the DUID and treats it as opaque blob. Also, NetworkManager (which uses this code) allows to configure the entire binary DUID in binary. It intentionally does not validate the binary content any further. Hence, it needs to be able to set _invalid_ DUIDs, provided that some basic constraints are satisfied (like the maximum length). sd_dhcp6_client_set_duid() has two callers: both set the DUID obtained from link_get_duid(), which comes from configuration. `man networkd.conf` says: "The configured DHCP DUID should conform to the specification in RFC 3315, RFC 6355.". It does not not state that it MUST conform. Note that dhcp_validate_duid_len() has another caller: DHCPv4's dhcp_client_set_iaid_duid_internal(). In this case, continue with strict validation, as the callers are more controlled. Also, there is already sd_dhcp_client_set_client_id() which can be used to bypass this check and set arbitrary client identifiers. Thomas Haller2018-12-204-6/+16
| * | | dhcp: don't enforce hardware address length for sd_dhcp_client_set_client_id()•••sd_dhcp_client_set_client_id() is the only API for setting a raw client-id. All other setters are more restricted and only allow to set a type 255 DUID. Also, dhcp4_set_client_identifier() is the only caller, which already does: r = sd_dhcp_client_set_client_id(link->dhcp_client, ARPHRD_ETHER, (const uint8_t *) &link->mac, sizeof(link->mac)); and hence ensures that the data length is indeed ETH_ALEN. Drop additional input validation from sd_dhcp_client_set_client_id(). The client-id is an opaque blob, and if a caller wishes to set type 1 (ethernet) or type 32 (infiniband) with unexpected address length, it should be allowed. The actual client-id is not relevant to the DHCP client, and it's the responsibility of the caller to generate a suitable client-id. For example, in NetworkManager you can configure all the bytes of the client-id, including such _invalid_ settings. I think it makes sense, to allow the user to fully configure the identifier. Even if such configuration would be rejected, it would be the responsibility of the higher layers (including a sensible error message to the user) and not fail later during sd_dhcp_client_set_client_id(). Still log a debug message if the length is unexpected. Thomas Haller2018-12-201-18/+11
| * | | dhcp: fix sd_dhcp_client_set_client_id() for infiniband addresses•••Infiniband addresses are 20 bytes (INFINIBAND_ALEN), but only the last 8 bytes are suitable for putting into the client-id. This bug had no effect for networkd, because sd_dhcp_client_set_client_id() has only one caller which always uses ARPHRD_ETHER type. I was unable to find good references for why this is correct ([1]). Fedora/RHEL has patches for ISC dhclient that also only use the last 8 bytes ([2], [3]). RFC 4390 (Dynamic Host Configuration Protocol (DHCP) over InfiniBand) [4] does not discuss the content of the client-id either. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1658057#c29 [2] https://bugzilla.redhat.com/show_bug.cgi?id=660681 [3] https://src.fedoraproject.org/rpms/dhcp/blob/3ccf3c8d815df4b8e11e1a04850975f099273d5d/f/dhcp-lpf-ib.patch [4] https://tools.ietf.org/html/rfc4390 Thomas Haller2018-12-201-1/+3
* | | | tree-wide: make new/new0/malloc_multiply/reallocarray safe for size 0•••All underlying glibc calls are free to return NULL if the size argument is 0. We most often call those functions with a fixed argument, or at least something which obviously cannot be zero, but it's too easy to forget. E.g. coverity complains about "rows = new0(JsonVariant*, n_rows-1);" in format-table.c There is an assert that n_rows > 0, so we could hit this corner case here. Let's simplify callers and make those functions "safe". CID #1397035. The compiler is mostly able to optimize this away: $ size build{,-opt}/src/shared/libsystemd-shared-239.so (before) text data bss dec hex filename 2643329 580940 3112 3227381 313ef5 build/src/shared/libsystemd-shared-239.so (-O0 -g) 2170013 578588 3089 2751690 29fcca build-opt/src/shared/libsystemd-shared-239.so (-03 -flto -g) (after) text data bss dec hex filename 2644017 580940 3112 3228069 3141a5 build/src/shared/libsystemd-shared-239.so 2170765 578588 3057 2752410 29ff9a build-opt/src/shared/libsystemd-shared-239.so Zbigniew Jędrzejewski-Szmek2018-12-212-4/+4
* | | | analyze: add assert to verify we are not dividing by 0•••CID #1397051. Zbigniew Jędrzejewski-Szmek2018-12-211-0/+1
* | | | udevadm: add two more assertions•••Suggested by Coverity. Closes CID#1397033 and CID#1395708. Yu Watanabe2018-12-211-2/+2
| |/ / |/| |
* | | hwdb: update database•••I looked over the diff, and it seems it's only additions and fixes, no removals. The diff for the source files is much bigger, but it seems that the sorting code is working well. Zbigniew Jędrzejewski-Szmek2018-12-2112-3080/+18273
* | | NEWS: mention DynamicUser= is disabled for networkd, resolved and timesyncd•••Which was disabled by #10117. Yu Watanabe2018-12-211-0/+9
* | | tests: explicitly enable user namespaces for TEST-13-NSPAWN-SMOKEFrantisek Sumsal2018-12-211-1/+6
* | | hwdb: Add accelerometer orientation quirk for the PoV TAB-P1006W-232-3G•••Add accelerometer orientation quirk for the Point of View TAB-P1006W-232-3G tablet. Hans de Goede2018-12-201-0/+4
* | | Merge pull request #11223 from poettering/read-line-0x00-0xff•••fileio: fix read_one_line() when reading bytes > 0x7FLennart Poettering2018-12-202-9/+16
|\ \ \
| * | | test-fileio: add explicit check for safe_fgetc() with 0xFFLennart Poettering2018-12-201-4/+5
| * | | fileio: fix read_one_line() when reading bytes > 0x7F•••Fixes: #11218 Lennart Poettering2018-12-202-5/+11
* | | | hwdb: Add support for HP ProBook 645 wifi and slash key (#11207)•••hwdb: Add support for HP ProBook 645 wifi and slash keyJeremy Su2018-12-201-0/+5
* | | | Merge pull request #11222 from keszybz/tmpfiles-crash•••tmpfiles: fix crash with NULL in arg_root and other fixes and testsLennart Poettering2018-12-202-9/+73
|\ \ \ \ | |/ / / |/| | |
| * | | tmpfiles: fix crash with NULL in arg_root and other fixes and tests•••The function to replacement paths into the configuration file list was borked. Apart from the crash with empty root prefix, it would incorrectly handle the case where root *was* set, and the replacement file was supposed to override an existing file. prefix_root is used instead of path_join because prefix_root removes duplicate slashes (when --root=dir/ is used). A test is added. Fixes #11124. Zbigniew Jędrzejewski-Szmek2018-12-202-9/+73
| |/ /
* | | Merge pull request #10912 from poettering/gpt-root-rw•••make sure to propagate GPT root partition r/w flag into mount r/w flagZbigniew Jędrzejewski-Szmek2018-12-204-48/+137
|\ \ \
| * | | update TODOLennart Poettering2018-12-181-3/+0
| * | | gpt-auto: propagate gpt partition ro/rw flag into root mount•••This ensures that the read/write state of the root mount matches the read/write flag in the GPT partition table entry. This is only used as fallback in case no ro/rw flag is specified on the kernel cmdline, and there's no entry for the root partition in /etc/fstab. This is missing functionality of the GPT auto logic, as without this the root partition was always mounted read-only — when booting with zero configuration in /etc/fstab and /proc/cmdline —, as we defaulted to read-only behaviour for all mounts. Moreover we honoured the r/o flag in the partition table for all other partition types, except for the root partition. Lennart Poettering2018-12-181-0/+43
| * | | gpt-auto: make arg_root_rw a tri-state•••No change in behaviour, but let's track whether ro or rw are specified on the kernel cmdline at all. Lennart Poettering2018-12-181-2/+2
| * | | remount-fs: optionally remount / writable, if we are told through an env varLennart Poettering2018-12-182-25/+63
| * | | remount-fs: split code for tracking PIDs in hashmap•••Just some refactoring, no change in behaviour. Lennart Poettering2018-12-181-18/+29
| * | | remount-fs: use PATH_IN_SET() at one more placeLennart Poettering2018-12-181-2/+1
| * | | gpt-auto: compare kernel cmdline args with proc_cmdline_key_streq()Lennart Poettering2018-12-181-5/+6
* | | | Merge pull request #11215 from poettering/gpt-auto-no-udev•••gpt-auto-generator: don't wait for udevZbigniew Jędrzejewski-Szmek2018-12-203-10/+33
|\ \ \ \ | |_|_|/ |/| | |
| * | | dissect: add some assert()sLennart Poettering2018-12-191-0/+15
| * | | gpt-auto-generator: don't wait for udev•••Generators run in a context where waiting for udev is not an option, simply because it's not running there yet. Hence, let's not wait for it in this case. This is generally OK to do as we are operating on the root disk only here, which should have been probed already by the time we come this far. An alternative fix might be to remove the udev dependency from image dissection again in the long run (and thus replace reliance on /dev/block/x:y somehow with something else). Fixes: #11205 Lennart Poettering2018-12-193-10/+18
|/ / /
* | | Merge pull request #11212 from keszybz/mount-storm-revert•••Revert the patches for mount-storm prevention for nowChris Down2018-12-192-100/+7
|\ \ \ | |_|/ |/| |
| * | Revert "core/mount: minimize impact on mount storm."•••This reverts commit 89f9752ea08f516b5d77f8e577bb772073c70c01. This patch causes various problems during boot, where a "mount storm" occurs naturally. Current approach is flakey, and it seems very risky to push a feature like this which impacts boot right before a release. So let's revert for now, and consider a more robust solution after later. Fixes #11209. > https://github.com/systemd/systemd/pull/11196#issuecomment-448523186: "Reverting 89f9752ea08f516b5d77f8e577bb772073c70c01 and fcfb1f775ed0e9d282607bb118ba788b98952855 fixes this test." Zbigniew Jędrzejewski-Szmek2018-12-192-76/+7
| * | Revert "mount: disable mount-storm protection while mount unit is starting."•••This reverts commit fcfb1f775ed0e9d282607bb118ba788b98952855. Zbigniew Jędrzejewski-Szmek2018-12-192-25/+1
|/ /
* | mount: disable mount-storm protection while mount unit is starting.•••The starting of mount units requires that changes to /proc/self/mountinfo be processed before the SIGCHILD from the completion of /sbin/mount is processed, as described by the comment /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded * before we process the SIGCHLD for the mount command. */ The recently-added mount-storm protection can defeat this as it will sometimes deliberately delay processing of /proc/self/mountinfo. So we need to disable mount-storm protection when a mount unit is starting. We do this by keeping a counter of the number of pending mounts, and disabling the protection when this is non-zero. Thanks to @asavah for finding and reporting this problem. NeilBrown2018-12-192-1/+25
* | Merge pull request #11201 from keszybz/more-news•••Some git history rewriting and more newsLennart Poettering2018-12-181-0/+20
|\ \
| * | NEWS: add a note about symlink following in .wants and .requires•••This ain't so easy to express without using too much technical language... https://github.com/systemd/systemd/pull/10094#issuecomment-427407570 Zbigniew Jędrzejewski-Szmek2018-12-181-0/+13
| * | NEWS: add note about NNP=yesZbigniew Jędrzejewski-Szmek2018-12-181-0/+7
| * | units: set NoNewPrivileges= for all long-running services•••Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. Fixes: #1219 Lennart Poettering2018-12-1815-0/+15
| * | units: sort [Service] sections alphabeticallyLennart Poettering2018-12-1815-171/+171
| * | Revert "units: set NoNewPrivileges= for all long-running services"•••This reverts commit 3ca9940cb95cb263c6bfe5cfee72df232fe46a94. Let's split the commit in two: the sorting and the changes. Because there's a requirement to update selinux policy, this change is incompatible, strictly speaking. I expect that distributions might want to revert this particular change. Let's make it easy. Zbigniew Jędrzejewski-Szmek2018-12-1815-186/+171
* | | Merge pull request #11182 from poettering/fileio-more-paranoia•••More safety checks for fileio.cLennart Poettering2018-12-188-136/+177
|\ \ \
| * | | test-fileio: test safe_fgetc directly•••Non-ascii chars are used so that we get both "positive" and "negative" characters (on the arches where char is signed). Zbigniew Jędrzejewski-Szmek2018-12-181-2/+30
| * | | update TODOLennart Poettering2018-12-181-26/+1
| * | | process-util: rework getenv_for_pid() to use read_nul_string()Lennart Poettering2018-12-181-19/+16
| * | | test: add test case for read_nul_string()Lennart Poettering2018-12-181-0/+35
| * | | fileio: let's minimize 'count' inc/dec calls•••instead of increasing it and immediately after decreasing it again, let's just increase it a bit later. Lennart Poettering2018-12-181-4/+3
| * | | fileio: replace read_nul_string() by read_line() with a special flag•••read_line() is a lot more careful and optimized than read_nul_string() but does mostly the same thing. let's replace the latter by the former, just with a special flag that toggles between the slightly different EOL rules if both. Lennart Poettering2018-12-183-53/+27
| * | | process-util: make get_process_environ() safer•••Let's add a size limit, and let's use safe_fgetc(). Lennart Poettering2018-12-181-10/+17
| * | | tree-wide: port some code over to safe_fgetc()Lennart Poettering2018-12-183-23/+20
| * | | fileio: add new safe_fgetc() helper call•••We have very similar code whenever we call fgetc() in place, let's replae it by a common implementation. Lennart Poettering2018-12-182-0/+29
* | | | Merge pull request #11203 from keszybz/json-no-slash-escaping•••json: do not unescape slashesChris Down2018-12-181-4/+0
|\ \ \ \ | |/ / / |/| | |
| * | | json: do not unescape slashes•••Apparently this originated in PHP, so the json output could be directly embedded in HTML script tags. See https://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped. Since the output of our tools is not intended directly for web page generation, let's not do this unescaping. If needed, the consumer can always do escaping as appropriate for the target format. Zbigniew Jędrzejewski-Szmek2018-12-181-4/+0
|/ / /
* | | Merge pull request #10221 from lucaswerkmeister/bash-completion•••Merged locally to resolve a conflict. The redirection of error is required to suppress "# Not showing unlisted system calls, ...". Zbigniew Jędrzejewski-Szmek2018-12-181-0/+11
|\ \ \ | |_|/ |/| |
| * | bash-completion: analyze: complete system call setsLucas Werkmeister2018-09-301-0/+11
* | | Merge pull request #11197 from keszybz/various-fixups•••Various fixupsLennart Poettering2018-12-185-10/+21
|\ \ \
| * | | test-mountpoint-util: more debug infoZbigniew Jędrzejewski-Szmek2018-12-181-4/+14
| * | | meson: print EFI CC configuration nicely•••In 595343fb4c99c2679d347ef7c19debfbfed6342e it was converted to an array. This doesn't look good in the output. Let's convert it back to a string. Zbigniew Jędrzejewski-Szmek2018-12-181-1/+1
| * | | meson: rename two more variables from _c to _sources•••_c is misleading because .h files should be included in those lists too (this tells meson that the build outputs should be rebuilt if the header files change). Follow-up for 1437822638ff9468fa78c7cfe56f8f55f955a61d. Zbigniew Jędrzejewski-Szmek2018-12-182-4/+4
| * | | systemctl: add comment why whitespace in message is neededZbigniew Jędrzejewski-Szmek2018-12-181-1/+2
* | | | Merge pull request #11191 from poettering/hashmap-clear•••rework hashmap_clear()Lennart Poettering2018-12-187-46/+263
|\ \ \ \ | |_|_|/ |/| | |
| * | | test-hashmap: add test to compare hashmap_free performance•••The point here is to compare speed of hashmap_destroy with free and a different freeing function, to the implementation details of hashmap_clear can be evaluated. Results: current code: /* test_hashmap_free (slow, 1048576 entries) */ string_hash_ops test took 2.494499s custom_free_hash_ops test took 2.640449s string_hash_ops test took 2.287734s custom_free_hash_ops test took 2.557632s string_hash_ops test took 2.299791s custom_free_hash_ops test took 2.586975s string_hash_ops test took 2.314099s custom_free_hash_ops test took 2.589327s string_hash_ops test took 2.319137s custom_free_hash_ops test took 2.584038s code with a patch which restores the "fast path" using: for (idx = skip_free_buckets(h, 0); idx != IDX_NIL; idx = skip_free_buckets(h, idx + 1)) in the case where both free_key and free_value are either free or NULL: /* test_hashmap_free (slow, 1048576 entries) */ string_hash_ops test took 2.347013s custom_free_hash_ops test took 2.585104s string_hash_ops test took 2.311583s custom_free_hash_ops test took 2.578388s string_hash_ops test took 2.283658s custom_free_hash_ops test took 2.621675s string_hash_ops test took 2.334675s custom_free_hash_ops test took 2.601568s So the test is noisy, but there clearly is no significant difference with the "fast path" restored. I'm surprised by this, but it shows that the current "safe" implementation does not cause a performance loss. When the code is compiled with optimization, those times are significantly lower (e.g. 1.1s and 1.4s), but again, there is no difference with the "fast path" restored. The difference between string_hash_ops and custom_free_hash_ops is the additional cost of global modification and the extra function call. Zbigniew Jędrzejewski-Szmek2018-12-182-0/+58
| * | | test-hashmap: use the usual function headers and print timing stats•••This makes it slightly easier to watch for performance changes. Zbigniew Jędrzejewski-Szmek2018-12-182-32/+48
| * | | hashmap: use ternary op to shorten codeZbigniew Jędrzejewski-Szmek2018-12-182-2/+2
| * | | lldp: add test coverage for sd_lldp_get_neighbors() with multiple neighbors•••In particular, check that the order of the results is consistent. This test coverage will be useful in order to refactor the compare_func used while sorting the results. When introduced, this test also uncovered a memory leak in sd_lldp_stop(), which was then fixed by a separate commit using a specialized function as destructor of the LLDP Hashmap. Tested: $ ninja -C build/ test $ valgrind --leak-check=full build/test-lldp Filipe Brandenburger2018-12-181-0/+130
| * | | sd-lldp: accept if a neighbor is already removed from the hashtableLennart Poettering2018-12-181-1/+6
| * | | hashmap: rework hashmap_clear() to be more defensive•••Let's first remove an item from the hashmap and only then destroy it. This makes sure that destructor functions can mdoify the hashtables in their own codee and we won't be confused by that. Lennart Poettering2018-12-182-11/+19
* | | | Merge pull request #11200 from poettering/mailmap-updates-240•••updates for .mailmap and NEWSZbigniew Jędrzejewski-Szmek2018-12-182-174/+217
|\ \ \ \
| * | | | NEWS: add one more itemLennart Poettering2018-12-181-0/+11