URL:
https://github.com/SSSD/sssd/pull/5370
Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented:
"""
Thank you for your inputs @alexey-tikhonov.
I think you are correct that we cannot rely on the file appearing zero filled following a
call to `posix_fallocate()`. There could then be a small race where a client does not
treat the cache file as
[
un-initialised](https://github.com/SSSD/sssd/blob/b913ddbd5aec9ea87ddbf10....
To prevent this, we could perhaps write `MC_HEADER_SIZE` zero bytes to the file and then
use `posix_fallocate()` for the remainder.
On the concern over the note in the glibc docs, the most obvious way I can see this
manifesting is when working with copy-on-write cloned files, which we aren't doing
here (however I guess there are other scenarios). It's also not clear if this note
relates only to the emulated behaviour of `posix_fallocate()`. I think it's fair to
say that the general behaviour of `posix_fallocate()` is closer to what we need than
`ftruncate()`, even with this caveat.
An alternative approach would be to use `fallocate(2)` with `FALLOC_FL_ZERO_RANGE`.
However since this is Linux specific, and `FALLOC_FL_ZERO_RANGE` is filesystem dependent
we would need a portable fallback (unless it's acceptable to disable the memcache in
this scenario).
The last, and probably most portable, approach would be to catch and gracefully handle
SIGBUS.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5370#issuecomment-709164015