Jan Kara <jack(a)suse.cz> writes:
commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has
removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the
mean time certain customer of ours started poking into /proc/<pid>/smaps
and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA
flags, the application just fails to start complaining that DAX support is
missing in the kernel. The question now is how do we go about this?
Strictly speaking, this is a userspace visible regression (as much as I
think that application poking into VMA flags at this level is just too
bold). Is there any precedens in handling similar issues with smaps which
really exposes a lot of information that is dependent on kernel
I have attached a patch that is an obvious "fix" for the issue - just fake
VM_MIXEDMAP flag in smaps. But I'm open to other suggestions...
I'm intrigued by the use case. Do I understand you correctly that the
database in question does not intend to make data persistent from
userspace? In other words, fsync/msync system calls are being issued by
I guess what I'm really after is a statement of requirements or
expectations. It would be great if you could convince the database
developer to engage in this discussion directly.