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 12BD6C433EF for ; Tue, 19 Apr 2022 11:47:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 759378D0067; Tue, 19 Apr 2022 07:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 707788D0047; Tue, 19 Apr 2022 07:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A82D8D0067; Tue, 19 Apr 2022 07:47:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 4A87D8D0047 for ; Tue, 19 Apr 2022 07:47:09 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1FF731564 for ; Tue, 19 Apr 2022 11:47:09 +0000 (UTC) X-FDA: 79373452578.23.B08ADE8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 12F8612000D for ; Tue, 19 Apr 2022 11:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650368828; h=from:from: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=SeAwfDT3x/Rkm2EZaznjRquYozKkI6xYPbRZ5Up9SYY=; b=CIGo2zKoLjke834JGxAFK45lSAIVagDGLOAcFgZFTU4eIKq1HgBrx9rn7JrcjvrcdKwzzh SuMQ6vGXq85/3BgFPvEB1K+AIO1pUEkBagIXZROYw561iHeV0vMVnG4ajV+P3G/ZpX5i13 ol2hcvMAk5iyjJp4JfeR4H6gnLq+Fck= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-629-746bCgdtMOGzIj8fhSVkxw-1; Tue, 19 Apr 2022 07:46:59 -0400 X-MC-Unique: 746bCgdtMOGzIj8fhSVkxw-1 Received: by mail-wm1-f70.google.com with SMTP id 125-20020a1c0283000000b003928cd3853aso741406wmc.9 for ; Tue, 19 Apr 2022 04:46:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=SeAwfDT3x/Rkm2EZaznjRquYozKkI6xYPbRZ5Up9SYY=; b=50+Xcsc2Vm/ukRykkccjODIlMhYISIcGmkb3Wms2fqZe0k1lt052YlU46ZGiII/z82 ikfZ26//vy707xCtIAQjZ0LMudKZ/CEuehQQ6JaSyaMd3Ta1UbuBsL6ux3zY49UktBDg 1E2sCizMi0WX+oPxJ4E+Ppd2XSbEjPiCUTzr4j7vCUCghPAn/HqEcNAs5XWSJs1Patp4 jNniLpo9WJ7P/MM168+c7u21Ra857i8wX7WUg5BV8+8N5rf27PetFxgYzF658FH0RpCn 5mSA/4/EUkfzanEh49tsK+sU4D3H3/5bXF5Z+VZAnDYI95oM1Tda2vyzrCz9uyLGft41 jOHg== X-Gm-Message-State: AOAM531H9tNoCwwTfMeTZL+2l033vdDZOEnKLvthfHS9Nkm0Xxc+oLqh DVHxIJKRBQ6ouzPCNHQslZQclymL9Ev0WU/8eqjnl6xu+g2GZg8S9mOUJmBrW+DLEpZGjZrsPZv fQ1ln5UpTZdw= X-Received: by 2002:a05:600c:4fd4:b0:392:91a7:acd3 with SMTP id o20-20020a05600c4fd400b0039291a7acd3mr11673234wmq.102.1650368818215; Tue, 19 Apr 2022 04:46:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDHXgAK0Ww+2rxrpDBFaWLh+Ig7M7331tmL3UVxIV72/e+ThWk1Oi28F4sEHs/+V1SMbpmHA== X-Received: by 2002:a05:600c:4fd4:b0:392:91a7:acd3 with SMTP id o20-20020a05600c4fd400b0039291a7acd3mr11673208wmq.102.1650368817960; Tue, 19 Apr 2022 04:46:57 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:5d00:d8c2:fbf6:a608:957a? (p200300cbc7045d00d8c2fbf6a608957a.dip0.t-ipconnect.de. [2003:cb:c704:5d00:d8c2:fbf6:a608:957a]) by smtp.gmail.com with ESMTPSA id o8-20020a5d6488000000b002051f1028f6sm13814890wri.111.2022.04.19.04.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 04:46:57 -0700 (PDT) Message-ID: Date: Tue, 19 Apr 2022 13:46:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2] mm/swapfile: unuse_pte can map random data if swap read fails To: Miaohe Lin , akpm@linux-foundation.org Cc: willy@infradead.org, vbabka@suse.cz, dhowells@redhat.com, neilb@suse.de, apopple@nvidia.com, surenb@google.com, minchan@kernel.org, peterx@redhat.com, sfr@canb.auug.org.au, rcampbell@nvidia.com, naoya.horiguchi@nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220416030549.60559-1-linmiaohe@huawei.com> <1b614ac3-02c0-ec66-b51a-e9b7e1a375ad@huawei.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <1b614ac3-02c0-ec66-b51a-e9b7e1a375ad@huawei.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CIGo2zKo; spf=none (imf29.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: mcor5iqtwxmo6k1ejrxk4aoxexjeybxt X-Rspamd-Queue-Id: 12F8612000D X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650368827-163516 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 19.04.22 13:21, Miaohe Lin wrote: > On 2022/4/19 15:37, David Hildenbrand wrote: >> On 16.04.22 05:05, 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. In case >>> of error, a special swap entry indicating swap read fails is set to the >>> page table. So the swapcache page can be freed and the user won't end up >>> with a permanently mounted swap because a sector is bad. And if the page >>> is accessed later, the user process will be killed so that corrupted data >>> is never consumed. On the other hand, if the page is never accessed, the >>> user won't even notice it. >>> >>> Signed-off-by: Miaohe Lin >>> --- >>> v2: >>> use special swap entry to avoid permanently mounted swap >>> free the bad page in swapcache >>> --- >>> include/linux/swap.h | 7 ++++++- >>> include/linux/swapops.h | 10 ++++++++++ >>> mm/memory.c | 5 ++++- >>> mm/swapfile.c | 11 +++++++++++ >>> 4 files changed, 31 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/linux/swap.h b/include/linux/swap.h >>> index d112434f85df..03c576111737 100644 >>> --- a/include/linux/swap.h >>> +++ b/include/linux/swap.h >>> @@ -55,6 +55,10 @@ static inline int current_is_kswapd(void) >>> * actions on faults. >>> */ >>> >>> +#define SWAP_READ_ERROR_NUM 1 >>> +#define SWAP_READ_ERROR (MAX_SWAPFILES + SWP_HWPOISON_NUM + \ >>> + SWP_MIGRATION_NUM + SWP_DEVICE_NUM + \ >>> + SWP_PTE_MARKER_NUM) >> >> Does anything speak against reusing the hwpoison marker? At least from a >> program POV it's similar "the previously well defined content at this >> user space address is no longer readable/writable". > > Looks like a good idea. :) > >> >> I recall that we can just set the pfn to 0 for the hwpoison marker. >> >> There is e.g., check_hwpoisoned_entry() and it just stops if it finds >> "pfn=0". > > Do you mean that we should set the pfn to 0 for the hwpoison marker so that we can > distinguish swapin error case from real hwpoison case? I am not sure if we really have to distinguish. However, "0" seems to make sense to indicate "this is not an actual problematic PFN, the information is simply no longer around due to a hardware issue. -- Thanks, David / dhildenb