Message ID | 20210904075458.51012-1-zhangyiru3@huawei.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [Vx,RESEND] mm,hugetlb: remove mlock ulimit for SHM_HUGETLB | expand |
On 9/4/21 12:54 AM, zhangyiru wrote: > remove mlock ulimit for SHM_HUGETLB > commit 21a3c273f88c9cbbaf7e ("mm, hugetlb: add thread name and pid to > SHM_HUGETLB mlock rlimit warning") marked this as deprecated in 2012, > but it is not deleted yet A better commit to mention would be 2584e517320b ("mm: reintroduce and deprecate rlimit based access for SHM_HUGETLB"). IIUC, 21a3c273f88c just modified the log message. There is nothing wrong with the code. Adding Andrew and Michal on Cc: as I have little or no experience with removing deprecated features/code. This certainly has been marked deprecated for a long time (since 2.6.31). However, I still see that message in log files on occasion. Andrew/Michal, comments?
On Tue, 7 Sep 2021 13:52:04 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote: > On 9/4/21 12:54 AM, zhangyiru wrote: > > remove mlock ulimit for SHM_HUGETLB > > commit 21a3c273f88c9cbbaf7e ("mm, hugetlb: add thread name and pid to > > SHM_HUGETLB mlock rlimit warning") marked this as deprecated in 2012, > > but it is not deleted yet > > A better commit to mention would be 2584e517320b ("mm: reintroduce and > deprecate rlimit based access for SHM_HUGETLB"). IIUC, 21a3c273f88c just > modified the log message. I made that change to the changelog. > There is nothing wrong with the code. Adding Andrew and Michal on Cc: > as I have little or no experience with removing deprecated > features/code. This certainly has been marked deprecated for a long > time (since 2.6.31). I'd have thought that emitting a nasty message for a decade would suffice. > However, I still see that message in log files on > occasion. However I appear to be wrong :( A quick web search indicates that people were reporting this in 2020, at least. So I don't think we can remove it. otoh, one report was against RHEL3 which went end-of-life in 2015. So perhaps some more research on this will end up making the justifiable. I dunno, I'm just waffling. Maybe just merge it and if someone complains, they can't say they weren't warned!
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index cdfb1ae78a3f..c092c4931c3e 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -1463,18 +1463,8 @@ struct file *hugetlb_file_setup(const char *name, size_t size, if (!mnt) return ERR_PTR(-ENOENT); - if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) { - *ucounts = current_ucounts(); - if (user_shm_lock(size, *ucounts)) { - task_lock(current); - pr_warn_once("%s (%d): Using mlock ulimits for SHM_HUGETLB is deprecated\n", - current->comm, current->pid); - task_unlock(current); - } else { - *ucounts = NULL; - return ERR_PTR(-EPERM); - } - } + if (creat_flags == HUGETLB_SHMFS_INODE && !can_do_hugetlb_shm()) + return ERR_PTR(-EPERM); file = ERR_PTR(-ENOSPC); inode = hugetlbfs_get_inode(mnt->mnt_sb, NULL, S_IFREG | S_IRWXUGO, 0);
remove mlock ulimit for SHM_HUGETLB commit 21a3c273f88c9cbbaf7e ("mm, hugetlb: add thread name and pid to SHM_HUGETLB mlock rlimit warning") marked this as deprecated in 2012, but it is not deleted yet Signed-off-by: zhangyiru <zhangyiru3@huawei.com> --- fs/hugetlbfs/inode.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-)