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 17EFBC433EF for ; Wed, 6 Apr 2022 08:45:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78FF06B0072; Wed, 6 Apr 2022 04:45:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73EE46B0073; Wed, 6 Apr 2022 04:45:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6067C6B0074; Wed, 6 Apr 2022 04:45:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 4CB066B0072 for ; Wed, 6 Apr 2022 04:45:08 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 89A8321D79 for ; Wed, 6 Apr 2022 08:44:57 +0000 (UTC) X-FDA: 79325819034.19.BBD0378 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf16.hostedemail.com (Postfix) with ESMTP id 9259A18002E for ; Wed, 6 Apr 2022 08:44:56 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KYJ1m4C47zgY7f; Wed, 6 Apr 2022 16:43:08 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 6 Apr 2022 16:44:52 +0800 Subject: Re: [PATCH] mm/swapfile: unuse_pte can map random data if swap read fails To: Andrew Morton CC: , , David Hildenbrand , Matthew Wilcox References: <20220401072926.45051-1-linmiaohe@huawei.com> <20220404155359.d4867fb8717fe40b5a11647c@linux-foundation.org> From: Miaohe Lin Message-ID: <90c87b53-42f4-875f-3be9-89c28eb4ade0@huawei.com> Date: Wed, 6 Apr 2022 16:44:52 +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: <20220404155359.d4867fb8717fe40b5a11647c@linux-foundation.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Stat-Signature: asgh5wigzp5obykfkp5gb1na5qr3b4s1 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9259A18002E Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspam-User: X-HE-Tag: 1649234696-695925 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 2022/4/5 6:53, Andrew Morton wrote: > On Fri, 1 Apr 2022 15:29:26 +0800 Miaohe Lin wrote: > >> There is a bug in unuse_pte(): when swap page happens to be unreadable, >> page filled with random data is mapped into user address space. The fix >> is to check for PageUptodate and fail swapoff in case of error. >> >> ... >> >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -1795,6 +1795,10 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, >> ret = 0; >> goto out; >> } >> + if (unlikely(!PageUptodate(page))) { >> + ret = -EIO; >> + goto out; >> + } >> >> dec_mm_counter(vma->vm_mm, MM_SWAPENTS); >> inc_mm_counter(vma->vm_mm, MM_ANONPAGES); > > Failing the swapoff after -EIO seems a bit rude. The user ends up with > a permanently mounted swap because a sector was bad? > This is really unfortunate. :( > That would be like failing truncate() or close() or umount after -EIO > on a regular file. Somewhat. > > Can we do something better? Such as shooting down the page anyway and > permitting the swapoff to proceed? Worst case, just leak the dang page > with an apologetic message. > . > We must have a way to prevent user from accessing the wrong data. One way is kept the page in the swap cache and kill the user when page is accessed. But this will end up with a permanently mounted swap. Another way I can figure out now is that we could set the page table entry to some special swap entry, such as SWP_EIO like SWP_HWPOISON, we can thus kill the user when page is accessed while swapoff can proceed. But this makes the code more complicated... Any suggestions? Many thanks!