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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23B49C636CD for ; Mon, 6 Feb 2023 00:48:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CF006B0072; Sun, 5 Feb 2023 19:48:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 389566B0073; Sun, 5 Feb 2023 19:48:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26D166B0074; Sun, 5 Feb 2023 19:48:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 18F246B0072 for ; Sun, 5 Feb 2023 19:48:17 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D3A4E1A0774 for ; Mon, 6 Feb 2023 00:48:16 +0000 (UTC) X-FDA: 80435030592.26.AF5F724 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf04.hostedemail.com (Postfix) with ESMTP id 882AE40009 for ; Mon, 6 Feb 2023 00:48:12 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675644494; a=rsa-sha256; cv=none; b=zqGdRVZkUimW+7fPx6GqX5BLTkMWgW2/GDyxUD0VeCBeAH71UGSYKYWxGAsLxSJJlp7pmY 71HWzA8c1KN/WDoAKTCa5/93oZPXeN3g5kkyQsqxDqhrr3TigBaVEqgDzHkXYrXuwT3lWr h0t6iWvwkiH+l6+foEVPwzPjSlbmpFw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675644494; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=23a27fDI3hai2A6CZLj6LRs6clKDCXMpwHk4/m7lHZE=; b=M4iBZnllMg3+tBLmXTy9lpMp9J80wAOqt4Uc1wceJc6DdsPIMCaV+vvsOtR7xzlt0wiRFo DOoSQyTExi3sNaRKgGHJFfiBGULowBahJsGg6QTQvSPsPDreXirCUUcO18FBtrKsTFpQtG Eld2bhzckiPsVoKZNQjPzEyz1tSy13A= Received: from dggpemm500014.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4P96yV4DtZzJsG5; Mon, 6 Feb 2023 08:46:26 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Mon, 6 Feb 2023 08:48:05 +0800 Message-ID: Date: Mon, 6 Feb 2023 08:48:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 CC: , , , , Subject: Re: [PATCH v3 1/4] mm/mlock: return EINVAL if len overflows for mlock/munlock Content-Language: en-US To: , References: <20230128063229.989058-1-mawupeng1@huawei.com> <20230128063229.989058-2-mawupeng1@huawei.com> <753c53d3-84a6-da73-4121-0db4a71e4fde@redhat.com> From: mawupeng In-Reply-To: <753c53d3-84a6-da73-4121-0db4a71e4fde@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 882AE40009 X-Rspamd-Server: rspam01 X-Stat-Signature: p54kxst7dc8b3dns56r4kin1uusofyrb X-HE-Tag: 1675644492-333844 X-HE-Meta: U2FsdGVkX18yclSKQxnwJTBb0bI7BGBzESjhvHtLu7Q32tpqFABQLblEkpbmeITg9cqVq/dvPK77gy14yCsoWbc3ndz3U845oGzdWUhCBUI05IsAGcj9DW3pUqFYe8pmfPW9ra1G9g3bsEVDTu6V35LrKUNk51JZx0V+eHaZObdgMVWDYMNr9JE6ikP12753kzy8uWRMaj8xwa/RLTLOCpr8gJFjG1oaPVJe2+4e4ccvwQWhSAP+nzoG5esWpl5ULfu1bqbP8+1ATaYGsLuHvOpRg5fgH8t3wdJoCwlfT1sN8+sa50eFmgKnRLC5gxNfyvIv+5pg2ip+wuFC47KU6Equv7yQN3HVacVua91eoVj+dqY9iGQqNyOoX+iZRvPnIuClpnmAK1pIxecoqxc4tk0BPxddnOH6rbnm6XVXwFQCCOkW7RkSpYKcJ9/TdN2Cu8rNyQjYtztNH5go8Fa2zH7mduewrUYVfRfRH/2habLShWMRPJWdlpGxojjk6SVMHhGXw08bK8GJ1QZp3bHBqT+BSXYilmJY4JQNzvEcxN1s91KIhJwQKYWtbHOdL/HF9gg9Quwovsmuq0iumc72UIzg6lTTxQwXP44+GM43GKXT8N1dh1Y5E49zFoX1h5oQj+ZA261jzh6ZGwANtCLlXVd+KT1KJqJ95rYHzB27p4VMJI2nrctmh588ZrOukfsLYtzkBI0ONOGzmM2vXlGOLWGunDTlseJt3DgFerWlPavgtK1XD5IR21+ZFoKGWP2nihaX0GrkSYdxwmb6m3PPkmmKow0zepjusZ1o4dNeqZoT2PT+JhnPJ6UHHoAmROnqveR2BLTh18rh2XS6x6ESJkL9b5sxjac6hAhfkDebzmGhsSDj44yZCcQTa9aG7LZp+8v3tUESU8k+xQmxnPWH/LBLedefIuhH1nMFIoLu+/iaoRRMzI4KQIDpudIZp2WV7sPJjC0UvvwPI/uPHam yhys9Iyd ++3rMRMa/+BfW/KMyAhY+f/riBSoLx5Z7IiBTf8II36dTM7IgUfEt4NuWjG2csgzCG4auMUkyY05meNnj3DmR9miHZrPTI5nMes0w6eqtI5BxixL+TsUPHKLoa+ao3zlDfYgUvXQEPQAMmflyqgnj//TwFbOi0KfmMKa1rprSFnIkHGY= 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 2023/2/4 1:14, David Hildenbrand wrote: > On 28.01.23 07:32, Wupeng Ma wrote: >> From: Ma Wupeng >> >> While testing mlock, we have a problem if the len of mlock is ULONG_MAX. >> The return value of mlock is zero. But nothing will be locked since the >> len in do_mlock overflows to zero due to the following code in mlock: >> >>    len = PAGE_ALIGN(len + (offset_in_page(start))); >> >> The same problem happens in munlock. >> >> Add new check and return -EINVAL to fix this overflowing scenarios since >> they are absolutely wrong. >> >> Return 0 early to avoid burn a bunch of cpu cycles if len == 0. >> >> Signed-off-by: Ma Wupeng >> --- >>   mm/mlock.c | 14 ++++++++++++-- >>   1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/mm/mlock.c b/mm/mlock.c >> index 7032f6dd0ce1..eb09968ba27f 100644 >> --- a/mm/mlock.c >> +++ b/mm/mlock.c >> @@ -478,8 +478,6 @@ static int apply_vma_lock_flags(unsigned long start, size_t len, >>       end = start + len; >>       if (end < start) >>           return -EINVAL; >> -    if (end == start) >> -        return 0; >>       vma = mas_walk(&mas); >>       if (!vma) >>           return -ENOMEM; >> @@ -575,7 +573,13 @@ static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t fla >>       if (!can_do_mlock()) >>           return -EPERM; >>   +    if (!len) >> +        return 0; >> + >>       len = PAGE_ALIGN(len + (offset_in_page(start))); >> +    if (!len) >> +        return -EINVAL; >> + >>       start &= PAGE_MASK; > > The "ordinary" overflows are detected in apply_vma_lock_flags(), correct? Overflow is not checked anywhere however the ordinary return early if len == 0 is detected in apply_vma_lock_flags(). do_mlock apply_vma_lock_flags end = start + len; if (end == start) return 0; Move the checking to the begin is easier to detect overflows and make the logic clearer and avoid burn a bunch of cpu cycles. >