summaryrefslogtreecommitdiffstats
path: root/hwdb.d/60-sensor.hwdb
diff options
context:
space:
mode:
authorSiddhesh Poyarekar <siddhesh@gotplt.org>2022-12-13 22:54:36 +0100
committerLennart Poettering <lennart@poettering.net>2022-12-14 17:49:47 +0100
commit7929e180aa47a2692ad4f053afac2857d7198758 (patch)
tree75acc7c7959371ca5106891f13df1d8662a2685d /hwdb.d/60-sensor.hwdb
parentswap: tell swapon to reinitialize swap if needed (diff)
downloadsystemd-7929e180aa47a2692ad4f053afac2857d7198758.tar.xz
systemd-7929e180aa47a2692ad4f053afac2857d7198758.zip
Use dummy allocator to make accesses defined as per standard
systemd uses malloc_usable_size() everywhere to use memory blocks obtained through malloc, but that is abuse since the malloc_usable_size() interface isn't meant for this kind of use, it is for diagnostics only. This is also why systemd behaviour is flaky when built with _FORTIFY_SOURCE. One way to make this more standard (and hence safer) is to, at every malloc_usable_size() call, also 'reallocate' the block so that the compiler can see the larger size. This is done through a dummy reallocator whose only purpose is to tell the compiler about the larger usable size, it doesn't do any actual reallocation. Florian Weimer pointed out that this doesn't solve the problem of an allocator potentially growing usable size at will, which will break the implicit assumption in systemd use that the value returned remains constant as long as the object is valid. The safest way to fix that is for systemd to step away from using malloc_usable_size() like this. Resolves #22801.
Diffstat (limited to 'hwdb.d/60-sensor.hwdb')
0 files changed, 0 insertions, 0 deletions