Re: [PATCH v4] mm,hugetlb: remove mlock ulimit for SHM_HUGETLB

[Mike Kravetz <mike.kravetz@oracle.com>]

On 11/1/21 12:01 AM, Hugh Dickins wrote:
> On Sat, 9 Oct 2021, zhangyiru wrote:
>>  fs/hugetlbfs/inode.c | 7 +++----
>>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> I have nothing against the obsoletion itself;
> but this patch appears to be incorrect, and far from complete.
> 
> Incorrect (unless we actually want to *punish* those who still use
> deprecated interfaces) because in these latest versions, it consumes
> from the mlock ulimit (if use_shm_lock() succeeds), but never gives
> back what it consumed.  I don't see why user_shm_lock() is called.

Thanks Hugh!

I was so focused on how how this might impact people still using the
deprecated feature, I missed this.

Since I have seen the 'this is deprecated' message as recently as this
year, I suspect this will impact someone.  The way it will impact them
is that their application will no longer work due to shmget() failing.
This is why it would be good idea to at least log a message saying someone
tried to use the obsolete feature.

The most convenient way to  determine if the call would have succeeded due
to the obsolete feature, is by using the existing user_shm_lock/unlock calls.
I suppose we could create a separate routine to just check the limit so that
a message can be printed.  Or, possibly open code.  But, I would advocate
for removing the 'this is obsolete' message in the next release.  When
we remove the message, we can eliminate the calls to user_shm_lock/unlock.

-- 
Mike Kravetz