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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 2A997C43460 for ; Tue, 11 May 2021 01:40:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE1A66162C for ; Tue, 11 May 2021 01:40:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE1A66162C Authentication-Results: mail.kernel.org; dmarc=fail (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 05DF16B006E; Mon, 10 May 2021 21:40:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00E5C6B0071; Mon, 10 May 2021 21:40:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E17D06B0072; Mon, 10 May 2021 21:40:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id C7D256B006E for ; Mon, 10 May 2021 21:40:40 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7AA6798BA for ; Tue, 11 May 2021 01:40:40 +0000 (UTC) X-FDA: 78127245840.13.C38F449 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf12.hostedemail.com (Postfix) with ESMTP id DDFF2132 for ; Tue, 11 May 2021 01:40:23 +0000 (UTC) Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FfLCS4THPzkWVG; Tue, 11 May 2021 09:37:56 +0800 (CST) Received: from [10.174.176.232] (10.174.176.232) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.498.0; Tue, 11 May 2021 09:40:33 +0800 Subject: Re: [PATCH] ksm: Revert "use GET_KSM_PAGE_NOLOCK to get ksm page in remove_rmap_item_from_tree()" To: Hugh Dickins CC: Andrew Morton , , References: <0e04877c-5b2d-b810-7464-108e793b84d3@huawei.com> From: Miaohe Lin Message-ID: Date: Tue, 11 May 2021 09:40:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.232] X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: DDFF2132 Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-Rspamd-Server: rspam04 X-Stat-Signature: bprnreembh1ifirk9nd5pxqpm5gfs1fp Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=szxga05-in.huawei.com; client-ip=45.249.212.191 X-HE-DKIM-Result: none/none X-HE-Tag: 1620697223-122577 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 2021/5/11 7:42, Hugh Dickins wrote: > On Mon, 10 May 2021, Miaohe Lin wrote: >> On 2021/5/10 13:59, Hugh Dickins wrote: >>> This reverts commit 3e96b6a2e9ad929a3230a22f4d64a74671a0720b. >>> General Protection Fault in rmap_walk_ksm() under memory pressure: >>> remove_rmap_item_from_tree() needs to take page lock, of course. >>> >> >> I'am really sorry about it! And many thanks for this bugfix! >> It seems rmap_walk_ksm() relies on the page lock to protect against >> concurrent modifications to that page's node of the stable tree. >> Could you please add a comment in remove_rmap_item_from_tree() to >> clarify this in case similar trouble again? Many thanks! > > Sorry, no. Page lock is held by callers of stable_tree_append() when > adding an rmap_item to the tree, and held by callers of rmap_walk_ksm() > (see VM_BUG_ON_PAGE there) when walking the tree: you would surely > expect some kind of locking when removing an rmap_item from the tree, > and the appropriate page lock is what GET_KSM_PAGE_LOCK provided. > > I do not want us to go through the kernel source adding a comment > /* We really mean to take this lock: it protects against concurrency */ > every time we take a lock in the kernel: you should generally assume > that if a lock is taken, then the writer intended it to be taken. > > There are sure to be some exceptions, where a lock is taken pointlessly: > but please look deeper before assuming that is the case. > I see. I should have been more careful. Many thanks for your detailed explanation and sorry about trouble! > Hugh > >> >>> Signed-off-by: Hugh Dickins >>> --- >>> >>> mm/ksm.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> --- 5.13-rc1/mm/ksm.c 2021-05-09 17:03:44.010422188 -0700 >>> +++ linux/mm/ksm.c 2021-05-09 22:12:39.403008350 -0700 >>> @@ -776,11 +776,12 @@ static void remove_rmap_item_from_tree(s >>> struct page *page; >>> >>> stable_node = rmap_item->head; >>> - page = get_ksm_page(stable_node, GET_KSM_PAGE_NOLOCK); >>> + page = get_ksm_page(stable_node, GET_KSM_PAGE_LOCK); >>> if (!page) >>> goto out; >>> >>> hlist_del(&rmap_item->hlist); >>> + unlock_page(page); >>> put_page(page); >>> >>> if (!hlist_empty(&stable_node->hlist)) > . >