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
