IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As far as I can see, we use this to get a list of ARPHRD_* defines (used in
particular for Type= in .link files). If we drop our copy, and build against
old kernel headers, the user will have a shorter list of types available. This
seems OK, and I don't think it's worth carrying our own version of this file
just to have newest possible entries.
7c5b9952c4f6e2b72f90edbe439982528b7cf223 recently updated this file, but we'd
have to update it every time the kernel adds new entries. But if we look at
the failure carefully:
src/basic/arphrd-from-name.gperf:65:16: error: ‘ARPHRD_MCTP’ undeclared (first use in this function); did you mean ‘ARPHRD_FCPP’?
65 | MCTP, ARPHRD_MCTP
| ^~
| ARPHRD_FCPP
we see that the list we were generating was from the system headers, so it was
only as good as the system headers anyway, without the newer entries in our
bundled copy, if there were any. So let's make things simpler by always using
system headers.
And if somebody wants to fix things so that we always have the newest list,
then we should just generate and store the converted list, not the full header.
In a follow-up patch we are going to modify the initrd, hence prepare
the pointers/"physical addresses" to it, first, so that we can do so
easily.
Also, do some other tweaks and cleanups to physical address/pointer
conversion.
Just like userspace realloc() the EFIlib ReallocatePool() function is
happy to use a NULL pointer as input, in which case it is equivalent to
AllocatePool(). See:
269ef9dbc7/lib/misc.c (L57)
Unfortunately, when checking the return/exit code using &&, ||, if,
while, etc., `set -e` is disabled for all nested functions as well,
which leads to incorrectly ignored errors, *sigh*.
Example:
```
set -eu
set -o pipefail
task() {
echo "task init"
echo "this should fail"
false
nonexistentcommand
echo "task end (we shouldn't be here)"
}
if ! task; then
echo >&2 "The task failed"
exit 1
else
echo "The task passed"
fi
```
```
$ bash test.sh
task init
this should fail
test.sh: line 10: nonexistentcommand: command not found
task end (we shouldn't be here)
The task passed
$ echo $?
0
```
But without the `if`, everything works "as expected":
```
set -eu
set -o pipefail
task() {
echo "task init"
echo "this should fail"
false
nonexistentcommand
echo "task end (we shouldn't be here)"
}
task
```
```
$ bash test.sh
task init
this should fail
$ echo $?
1
```
Wonderful.
to suppress OpenSSL 3.0 deprecation warnings (until a proper solution
is deployed):
```
../src/shared/creds-util.c: In function ‘sha256_hash_host_and_tpm2_key’:
../src/shared/creds-util.c:412:9: error: ‘SHA256_Init’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
412 | if (SHA256_Init(&sha256_context) != 1)
| ^~
In file included from /usr/include/openssl/x509.h:41,
from ../src/shared/openssl-util.h:8,
from ../src/shared/creds-util.c:21:
/usr/include/openssl/sha.h:73:27: note: declared here
73 | OSSL_DEPRECATEDIN_3_0 int SHA256_Init(SHA256_CTX *c);
| ^~~~~~~~~~~
../src/shared/creds-util.c:415:9: error: ‘SHA256_Update’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
415 | if (host_key && SHA256_Update(&sha256_context, host_key, host_key_size) != 1)
| ^~
In file included from /usr/include/openssl/x509.h:41,
from ../src/shared/openssl-util.h:8,
from ../src/shared/creds-util.c:21:
/usr/include/openssl/sha.h:74:27: note: declared here
74 | OSSL_DEPRECATEDIN_3_0 int SHA256_Update(SHA256_CTX *c,
| ^~~~~~~~~~~~~
../src/shared/creds-util.c:418:9: error: ‘SHA256_Update’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
418 | if (tpm2_key && SHA256_Update(&sha256_context, tpm2_key, tpm2_key_size) != 1)
| ^~
In file included from /usr/include/openssl/x509.h:41,
from ../src/shared/openssl-util.h:8,
from ../src/shared/creds-util.c:21:
/usr/include/openssl/sha.h:74:27: note: declared here
74 | OSSL_DEPRECATEDIN_3_0 int SHA256_Update(SHA256_CTX *c,
| ^~~~~~~~~~~~~
../src/shared/creds-util.c:421:9: error: ‘SHA256_Final’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
421 | if (SHA256_Final(ret, &sha256_context) != 1)
| ^~
In file included from /usr/include/openssl/x509.h:41,
from ../src/shared/openssl-util.h:8,
from ../src/shared/creds-util.c:21:
/usr/include/openssl/sha.h:76:27: note: declared here
76 | OSSL_DEPRECATEDIN_3_0 int SHA256_Final(unsigned char *md, SHA256_CTX *c);
| ^~~~~~~~~~~~
cc1: all warnings being treated as errors
```
i.e. let's pick some files we know are too large, or where struct stat's
.st_size is zero even though non-empty, and test read_virtual_file()
with that, to ensure things are handled sensibly. Goal is to ensure all
three major codepaths in read_virtual_file() are tested.
Prompted-by: #20743
We mishandled the case where the size we read from the file actually
matched the maximum size fully. In that case we cannot really make a
determination whether the file was fully read or only partially. In that
case let's do another loop, so that we operate with a buffer, and
we can detect the EOF (which will be signalled to us via a short read).
There's a very gradual increase of anonymous memory in systemd-journald that
blames to 2ac67221bb6270f0fbe7cbd0076653832cd49de2.
systemd-journald makes many calls to read /proc/PID/cmdline and
/proc/PID/status, both of which tend to be well under 4K. However the
combination of allocating 4M read buffers, then using `realloc()` to
shrink the buffer in `read_virtual_file()` appears to be creating
fragmentation in the heap (when combined with the other allocations
systemd-journald is doing).
To help mitigate this, try reading /proc with a 4K buffer as
`read_virtual_file()` did before 2ac67221bb6270f0fbe7cbd0076653832cd49de2.
If it isn't big enough then try again with the larger buffers.
According to the documentation, Setting the data threshold to zero disables the
data threshold alltogether. Let's make sure we actually implement this behaviour
in sd_journal_enumerate_fields() by only applying the data threshold if it exceeds
zero.
