Jan Kara <jack@xxxxxxx> writes: > Hello, > > 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 > implementation details? > > 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... Hi, Jan, 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 the database? 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. Cheers, Jeff
