On Thu, 15 Nov 2018, Michal Hocko wrote:

quoted

The userspace had a single way to determine if thp had been disabled for a 
specific vma and that was broken with your commit.  We have since fixed 
it.  Modifying our software stack to start looking for some field 
somewhere else will not help anybody else that this has affected or will 
affect.  I'm interested in not breaking userspace, not trying a wait and 
see approach to see if anybody else complains once we start looking for 
some other field.  The risk outweighs the reward, it already broke us, and 
I'd prefer not to even open the possibility of breaking anybody else.

I very much agree on "do not break userspace" part but this is kind of
gray area. VMA flags are a deep internal implementation detail and
nobody should really depend on it for anything important. The original
motivation for introducing it was CRIU where it is kind of
understandable. I would argue they should find a different way but it is
just too late for them.

For this particular case there was no other bug report except for yours
and if it is possible to fix it on your end then I would really love to
make the a sensible user interface to query the status. If we are going
to change the semantic of the exported flag again then we risk yet
another breakage.

Therefore I am asking whether changing your particular usecase to a new
interface is possible because that would allow to have a longerm
sensible user interface rather than another kludge which still doesn't
cover all the usecases (e.g. there is no way to reliably query the
madvise status after your patch).

Providing another interface is great, I have no objection other than 
emitting another line for every vma on the system for smaps is probably 
overkill for something as rare as PR_SET_THP_DISABLE.

That said, I think the current handling of the "nh" flag being emitted in 
smaps is logical and ensures no further userspace breakage.  If that is to 
be removed, I consider it an unnecessary risk.  That would raised in code 
review.