From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EE2AC433EF for ; Mon, 1 Nov 2021 07:02:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A1B760C40 for ; Mon, 1 Nov 2021 07:02:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3A1B760C40 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C1BA46B00A6; Mon, 1 Nov 2021 03:02:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCB396B00A7; Mon, 1 Nov 2021 03:02:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB99C80008; Mon, 1 Nov 2021 03:02:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 9A2756B00A6 for ; Mon, 1 Nov 2021 03:02:04 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3F2E332610 for ; Mon, 1 Nov 2021 07:02:04 +0000 (UTC) X-FDA: 78759467010.01.E5E32BC Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by imf17.hostedemail.com (Postfix) with ESMTP id E2E32F000396 for ; Mon, 1 Nov 2021 07:02:03 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id o10-20020a9d718a000000b00554a0fe7ba0so18229202otj.11 for ; Mon, 01 Nov 2021 00:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=rbZF9gAW7yd/NQoDL4ZVZ7n7H2fp2I3yqYqYK96btqo=; b=LWznGZ/1SwpVxxj4+OfuFCz1XxH5xlSlQDhKg79DKBEU+8kRQ7Gmomab6/XrfvxC0Y 61OwRa60WX2G8FpBX8D9Se1Qq9fIQuaE5iO2/zs+rdDg27lrT3AiIs2AcqOmdnGHs1kb keXEb5i1RkJV3wZciGKj/MGxgnav29jTOzE82zkS+H5dVZCdqKBYMDuNVXqxT5YdAtB4 5yu4BPKR1RO/wOrUpum0JRn4DCMLbFUdI9JVrB6AN2hD40Fg0jctxvVP7MUAW46SVZJa S5a9DX0znQCANDquYWcyDozWhtWcez9oouXY4EO0HqIpf2ud8Mf9CtYKMvB6tZL+AFy9 E8Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=rbZF9gAW7yd/NQoDL4ZVZ7n7H2fp2I3yqYqYK96btqo=; b=La5ht6R15hFi9dvLkooE3o31+q2fNuTwDdPTfVVLV8TKDg3AuVBan1RP84JzLl0qv7 poXVUS7tS1GIzAVzzW8LTmHMXS57VcnuCv/IbjIbNyjmFmLRdw+1UgiDBpFNZJVleTvc 5mpyn0pZQxwjtb9eMQpvMbnPAmjH1hjquPVoTW+g3jOvnEhTohYWFQQqvuxSIsno2XK8 wV/DgXygpfIBB62yVXD4Q62Xp+MbwOi/ENC6hQE2l6y4cZ+ftVYdyyPP4G8zNN/iWcEs i3VBCwHDtPOVCf0aEPonaxvc2w4TMbMr5fe7l7LhrEXsNCNcYikhYKDrijDjnZgOKXbV 2uBA== X-Gm-Message-State: AOAM532A/0fZzex4xaA9DdiqTxxfIPBjv45u0At6DB4AUc3F8sPsw7ox dQ5kzu2vW8buCx/o2n8dQmhjxQ== X-Google-Smtp-Source: ABdhPJy94ChhYu36yBGS0ItxmucMHdVK1gXJVxtWmyuUCU8uB4jC56xPSBa+isj6TfjH66S37Z0Qfg== X-Received: by 2002:a9d:2923:: with SMTP id d32mr18918041otb.149.1635750123008; Mon, 01 Nov 2021 00:02:03 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id p201sm3134448oop.6.2021.11.01.00.02.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 00:02:01 -0700 (PDT) Date: Mon, 1 Nov 2021 00:01:48 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: zhangyiru cc: mike.kravetz@oracle.com, akpm@linux-foundation.org, linux-mm@kvack.org, mhocko@suse.com, wuxu.wu@huawei.com, liusirui@huawei.com, liuzixian4@huawei.com Subject: Re: [PATCH v4] mm,hugetlb: remove mlock ulimit for SHM_HUGETLB In-Reply-To: <20211009094355.127705-1-zhangyiru3@huawei.com> Message-ID: <17d4c5c5-af74-c6d1-f05d-1c2078c2d6a@google.com> References: <20211009094355.127705-1-zhangyiru3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: 7dh8sx5461fdfy6ug8sxu9yjhgkroe6z Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="LWznGZ/1"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of hughd@google.com designates 209.85.210.54 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E2E32F000396 X-HE-Tag: 1635750123-784269 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, 9 Oct 2021, zhangyiru wrote: > 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. > > Mike says he still see that message in log files on occasion, > so maybe we should preserve this warning. > > Signed-off-by: zhangyiru > --- > Changelog: > v4: modify context information of obsolete > v3: modify warning message to obsolete > v2: preserve warning message > v1: remove mlock ulimit for SHM_HUGETLB > --- > fs/hugetlbfs/inode.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index cdfb1ae78a3f..5ff3418759ed 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -1467,13 +1467,12 @@ struct file *hugetlb_file_setup(const char *name, size_t size, > *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", > + pr_warn_once("%s (%d): Using mlock ulimits for SHM_HUGETLB is obsolete\n", > current->comm, current->pid); > task_unlock(current); > - } else { > - *ucounts = NULL; > - return ERR_PTR(-EPERM); > } > + *ucounts = NULL; > + return ERR_PTR(-EPERM); > } > > file = ERR_PTR(-ENOSPC); > -- > 2.27.0 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. Incomplete, because further down (at the "out" label) there's a pointless call to user_shm_unlock(), which should be removed. Far from complete, because why is there even a ucounts argument to hugetlb_file_setup() now? That should be removed too, and ipc/shm.c adjusted (but it still needs shp->mlock_ucounts for the shmem case). (Sorry, I'm being totally unresponsive at present, needing to focus on something else; but thought I'd better get these comments in before mmotm's mmhugetlb-remove-mlock-ulimit-for-shm_hugetlb.patch goes to 5.16.) Hugh