Miklos, thanks for your program. Its output is given below.
debian:~/miklos# mount | grep mnt
tmpfs on /mnt type tmpfs (rw)
debian:~/miklos# ./miklos /mnt/file
begin 1201089989 1201089989 1201085868
write 1201089990 1201089990 1201085868
mmap 1201089990 1201089990 1201089991
store b 1201089992 1201089992 1201089991
msync 1201089992 1201089992 1201089991
store c 1201089994 1201089994 1201089991
msync 1201089994 1201089994 1201089991
store d 1201089996 1201089996 1201089991
munmap 1201089996 1201089996 1201089991
close 1201089996 1201089996 1201089991
sync 1201089996 1201089996 1201089991
debian:~/miklos# ./miklos /mnt/file -r
begin 1201090025 1201090025 1201089991
write 1201090026 1201090026 1201089991
mmap 1201090026 1201090026 1201090027
fetch x 1201090026 1201090026 1201090027
store b 1201090026 1201090026 1201090027
msync 1201090026 1201090026 1201090027
fetch y 1201090026 1201090026 1201090027
store c 1201090032 1201090032 1201090027
msync 1201090032 1201090032 1201090027
fetch z 1201090032 1201090032 1201090027
store d 1201090036 1201090036 1201090027
munmap 1201090036 1201090036 1201090027
close 1201090036 1201090036 1201090027
sync 1201090036 1201090036 1201090027
debian:~/miklos#
I think that after the patches applied the msync() system call does
everything, which it is expected to do. The issue you're now talking
about is one belonging to do_fsync() and the design of the tmpfs
driver itself, I believe. Indeed, when the first write in the "-r"
version of the test did not update the stamps, this is obviously not
an msync() guilt.
By the way, I would not like to move the "4/4" patch to the earlier
place, because then it would describe the functionality, which had not
been introduced yet.
--