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 X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66769C433E7 for ; Thu, 15 Oct 2020 13:19:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98E3E2225C for ; Thu, 15 Oct 2020 13:19:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98E3E2225C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0866B6B006E; Thu, 15 Oct 2020 09:19:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 038826B0070; Thu, 15 Oct 2020 09:19:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E69E86B0071; Thu, 15 Oct 2020 09:19:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id BA2296B006E for ; Thu, 15 Oct 2020 09:19:20 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 49A4D181AC9C6 for ; Thu, 15 Oct 2020 13:19:20 +0000 (UTC) X-FDA: 77374216080.15.boy13_59018dc27214 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 242F31814B0C7 for ; Thu, 15 Oct 2020 13:19:20 +0000 (UTC) X-HE-Tag: boy13_59018dc27214 X-Filterd-Recvd-Size: 3141 Received: from huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Thu, 15 Oct 2020 13:19:19 +0000 (UTC) Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id E6C65124808B93566D67; Thu, 15 Oct 2020 21:19:13 +0800 (CST) Received: from [10.174.177.6] (10.174.177.6) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.487.0; Thu, 15 Oct 2020 21:19:06 +0800 Subject: Re: [PATCH] mm: fix potential pte_unmap_unlock pte error To: CC: , , , , References: <20201015121534.50910-1-luoshijie1@huawei.com> From: Shijie Luo Message-ID: <5cfdd51c-c539-5d30-6388-168dfd83f6b5@huawei.com> Date: Thu, 15 Oct 2020 21:19:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US X-Originating-IP: [10.174.177.6] X-CFilter-Loop: Reflected Content-Transfer-Encoding: quoted-printable 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 2020/10/15 20:58, osalvador@suse.de wrote: > On 2020-10-15 14:15, Shijie Luo wrote: >> When flags don't have MPOL_MF_MOVE or MPOL_MF_MOVE_ALL bits, code brea= ks >> =C2=A0and passing origin pte - 1 to pte_unmap_unlock seems like not a = good=20 >> idea. >> >> Signed-off-by: Shijie Luo >> Signed-off-by: linmiaohe >> --- >> =C2=A0mm/mempolicy.c | 6 +++++- >> =C2=A01 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/mm/mempolicy.c b/mm/mempolicy.c >> index 3fde772ef5ef..01f088630d1d 100644 >> --- a/mm/mempolicy.c >> +++ b/mm/mempolicy.c >> @@ -571,7 +571,11 @@ static int queue_pages_pte_range(pmd_t *pmd, >> unsigned long addr, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } else >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= break; >> =C2=A0=C2=A0=C2=A0=C2=A0 } >> -=C2=A0=C2=A0=C2=A0 pte_unmap_unlock(pte - 1, ptl); >> + >> +=C2=A0=C2=A0=C2=A0 if (addr >=3D end) >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pte =3D pte - 1; >> + >> +=C2=A0=C2=A0=C2=A0 pte_unmap_unlock(pte, ptl); > > But this is still wrong, isn't it? > Unless I am missing something, this is "only" important under=20 > CONFIG_HIGHPTE. > > We have: > > pte =3D pte_offset_map_lock(walk->mm, pmd, addr, &ptl); > > which under CONFIG_HIGHPTE does a kmap_atomoc. > > Now, we either break the loop in the first pass because of=20 > !(MPOL_MF_MOVE | MPOL_MF_MOVE_ALL), > or we keep incrementing pte by every pass. > Either way is wrong, because the pointer kunmap_atomic gets will not=20 > be the same (since we incremented pte). > > Or is the loop meant to be running only once, so pte - 1 will bring us=20 > back to the original pte? > > . Thanks for your reply, if we break the loop in the first pass, the pte=20 pointer will not be incremented, pte - 1 equals original pte - 1,=C2=A0 because we only increase pte point= er=20 when not break the loop.