On Tue 02-10-18 12:50:58, Michal Hocko wrote:
On Tue 02-10-18 12:05:31, Jan Kara wrote:
> commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax"
> 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
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  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.
Jan Kara <jack(a)suse.com>
SUSE Labs, CR