On Tue 02-10-18 12:50:58, Michal Hocko wrote: > On Tue 02-10-18 12:05:31, Jan Kara wrote: > > 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? > > Do they need to check for a general DAX support or do they need a per > mapping granularity? General DAX support per filesystem is OK for them, at least for now. So they might be OK with just checking for 'dax' mount option in /proc/mounts. But I agree this is cumbersome. > > 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? > > Yeah, exposing all the vma flags was just a terrible idea. We have had a > similar issue recently [1] for other flag that is no longer set while > the implementation of the feature is still in place. I guess we really > want to document that those flags are for debugging only and no stable > and long term API should rely on it. Yeah, I have some doubts about usefulness of such documentation but I guess it's better than nothing. > Considering how new the thing really is (does anybody do anything > production like out there?) I would tend to try a better interface > rather than chasing after random vma flags. E.g. what prevents a > completely unrelated usage of VM_MIXEDMAP? Nothing checking that flag is in production AFAIK but DAX as such is in active use for some limited usecases already. I'll reply regarding a better interface for checking DAX, in an email to Johannes. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
