Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | tmpfiles: fix crash with NULL in arg_root and other fixes and testsZbigniew Jędrzejewski-Szmek2018-12-202-9/+73
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #10912 from poettering/gpt-root-rwZbigniew Jędrzejewski-Szmek2018-12-204-56/+145
|\ \ \ | | | | | | | | make sure to propagate GPT root partition r/w flag into mount r/w flag
| * | | update TODOLennart Poettering2018-12-181-3/+0
| | | |
| * | | gpt-auto: propagate gpt partition ro/rw flag into root mountLennart Poettering2018-12-181-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | gpt-auto: make arg_root_rw a tri-stateLennart Poettering2018-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | No change in behaviour, but let's track whether ro or rw are specified on the kernel cmdline at all.
| * | | remount-fs: optionally remount / writable, if we are told through an env varLennart Poettering2018-12-182-30/+68
| | | |
| * | | remount-fs: split code for tracking PIDs in hashmapLennart Poettering2018-12-181-18/+29
| | | | | | | | | | | | | | | | Just some refactoring, no change in behaviour.
| * | | 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-udevZbigniew Jędrzejewski-Szmek2018-12-203-10/+33
|\ \ \ \ | |_|_|/ |/| | | gpt-auto-generator: don't wait for udev
| * | | dissect: add some assert()sLennart Poettering2018-12-191-0/+15
| | | |
| * | | gpt-auto-generator: don't wait for udevLennart Poettering2018-12-193-10/+18
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge pull request #11212 from keszybz/mount-storm-revertChris Down2018-12-192-100/+7
|\ \ \ | |_|/ |/| | Revert the patches for mount-storm prevention for now
| * | Revert "core/mount: minimize impact on mount storm."Zbigniew Jędrzejewski-Szmek2018-12-192-76/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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."
| * | Revert "mount: disable mount-storm protection while mount unit is starting."Zbigniew Jędrzejewski-Szmek2018-12-192-25/+1
|/ / | | | | | | This reverts commit fcfb1f775ed0e9d282607bb118ba788b98952855.
* | mount: disable mount-storm protection while mount unit is starting.NeilBrown2018-12-192-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #11201 from keszybz/more-newsLennart Poettering2018-12-181-0/+20
|\ \ | | | | | | Some git history rewriting and more news
| * | NEWS: add a note about symlink following in .wants and .requiresZbigniew Jędrzejewski-Szmek2018-12-181-0/+13
| | | | | | | | | | | | | | | | | | This ain't so easy to express without using too much technical language... https://github.com/systemd/systemd/pull/10094#issuecomment-427407570
| * | NEWS: add note about NNP=yesZbigniew Jędrzejewski-Szmek2018-12-181-0/+7
| | |
| * | units: set NoNewPrivileges= for all long-running servicesLennart Poettering2018-12-1815-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | units: sort [Service] sections alphabeticallyLennart Poettering2018-12-1815-171/+171
| | |
| * | Revert "units: set NoNewPrivileges= for all long-running services"Zbigniew Jędrzejewski-Szmek2018-12-1815-186/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #11182 from poettering/fileio-more-paranoiaLennart Poettering2018-12-188-136/+177
|\ \ \ | | | | | | | | More safety checks for fileio.c
| * | | test-fileio: test safe_fgetc directlyZbigniew Jędrzejewski-Szmek2018-12-181-2/+30
| | | | | | | | | | | | | | | | | | | | Non-ascii chars are used so that we get both "positive" and "negative" characters (on the arches where char is signed).
| * | | 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 callsLennart Poettering2018-12-181-4/+3
| | | | | | | | | | | | | | | | | | | | instead of increasing it and immediately after decreasing it again, let's just increase it a bit later.
| * | | fileio: replace read_nul_string() by read_line() with a special flagLennart Poettering2018-12-183-53/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | process-util: make get_process_environ() saferLennart Poettering2018-12-181-10/+17
| | | | | | | | | | | | | | | | Let's add a size limit, and let's use safe_fgetc().
| * | | tree-wide: port some code over to safe_fgetc()Lennart Poettering2018-12-183-23/+20
| | | |
| * | | fileio: add new safe_fgetc() helper callLennart Poettering2018-12-182-0/+29
| | | | | | | | | | | | | | | | | | | | We have very similar code whenever we call fgetc() in place, let's replae it by a common implementation.
* | | | Merge pull request #11203 from keszybz/json-no-slash-escapingChris Down2018-12-181-4/+0
|\ \ \ \ | |/ / / |/| | | json: do not unescape slashes
| * | | json: do not unescape slashesZbigniew Jędrzejewski-Szmek2018-12-181-4/+0
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #10221 from lucaswerkmeister/bash-completionZbigniew Jędrzejewski-Szmek2018-12-181-0/+11
|\ \ \ | |_|/ |/| | | | | | | | Merged locally to resolve a conflict. The redirection of error is required to suppress "# Not showing unlisted system calls, ...".
| * | bash-completion: analyze: complete system call setsLucas Werkmeister2018-09-301-0/+11
| | |
* | | Merge pull request #11197 from keszybz/various-fixupsLennart Poettering2018-12-185-10/+21
|\ \ \ | | | | | | | | Various fixups
| * | | test-mountpoint-util: more debug infoZbigniew Jędrzejewski-Szmek2018-12-181-4/+14
| | | |
| * | | meson: print EFI CC configuration nicelyZbigniew Jędrzejewski-Szmek2018-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | In 595343fb4c99c2679d347ef7c19debfbfed6342e it was converted to an array. This doesn't look good in the output. Let's convert it back to a string.
| * | | meson: rename two more variables from _c to _sourcesZbigniew Jędrzejewski-Szmek2018-12-182-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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.
| * | | systemctl: add comment why whitespace in message is neededZbigniew Jędrzejewski-Szmek2018-12-181-1/+2
| | | |
* | | | Merge pull request #11191 from poettering/hashmap-clearLennart Poettering2018-12-187-46/+263
|\ \ \ \ | |_|_|/ |/| | | rework hashmap_clear()
| * | | test-hashmap: add test to compare hashmap_free performanceZbigniew Jędrzejewski-Szmek2018-12-182-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | test-hashmap: use the usual function headers and print timing statsZbigniew Jędrzejewski-Szmek2018-12-182-32/+48
| | | | | | | | | | | | | | | | This makes it slightly easier to watch for performance changes.
| * | | 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 neighborsFilipe Brandenburger2018-12-181-0/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | sd-lldp: accept if a neighbor is already removed from the hashtableLennart Poettering2018-12-181-1/+6
| | | |
| * | | hashmap: rework hashmap_clear() to be more defensiveLennart Poettering2018-12-182-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #11200 from poettering/mailmap-updates-240Zbigniew Jędrzejewski-Szmek2018-12-182-175/+218
|\ \ \ \ | | | | | | | | | | updates for .mailmap and NEWS
| * | | | NEWS: add one more itemLennart Poettering2018-12-181-0/+11
| | | | |