mjhjmtu

From fsync(2):

fsync() transfers ("flushes") all modified in-core data of (i.e., modified
buffer cache pages for) the file referred to by the file descriptor fd to
the disk device (or other permanent storage device)

What effects can fsync have if fd was obtained by one of the in-memory
APIs like shm_open(3p) or `memfd_create(2)*? Is it ever necessary to
explicitly commit changes to the memory object?

No effect. It is not associated with permanent storage.

Historically, mixing mmap() and read()/write() could give inconsistent results.

Modern Linux is very carefully structured to make it work correctly on every supported CPU. Though if your system is too obscure, you could still be the unlucky person who finds a hardware-specific bug.

The point is that on a POSIX-conforming OS, it could be necessary to use msync() to flush after writing changes to a memory-map of a file, if you want read() to work consistently afterwards. If you want to understand the POSIX rules, it might be helpful to look at the MS_INVALIDATE flag of msync(), and what its existence implies :).

However, POSIX msync() is specifically targeted at mappings which are associated with persistent storage. It is left undefined what effect it has on "shared memory objects". So this would be a pretty obscure way to answer your original question.

Also bear in mind that just because something implements a system call with the same name as the POSIX one, it doesn't necessarily provide all the same guarantees as POSIX. Only a small number of OS versions have actually been submitted to the POSIX test suite. (It costs money).