Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2785850pxb; Mon, 25 Apr 2022 02:22:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxiPRvILibNXVp9EW8akXDx4TpIrS4wN0lmAt1U7Hc8wZgGtemIjUJ+VOGzeGC0iljT0Buy X-Received: by 2002:a17:903:120c:b0:154:c135:60d3 with SMTP id l12-20020a170903120c00b00154c13560d3mr17055554plh.48.1650878527457; Mon, 25 Apr 2022 02:22:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650878527; cv=none; d=google.com; s=arc-20160816; b=m2pxmgexS+bgp8Q9+sO4ZQ/vkdQWg424zrbzqv0P4Hb9zJkJOdzBFKQxH4GMekWfbS EeGh8Ur5Xqvsp3DHRGseicoXIqIoN+9F06J350FA4c5KL7yiJ23mNuARdkUgmVoft+8p iUHYuJHVJkUCNoTMfjFGrwg/txbIrDcBbo/+EHusXRG1PXXBR3lhN90JWhg3d1XSwQC4 hu6Ui8/Dn/Hp9mMHPuaEsdel5kKwZk69Xvn4oiGEpzg+V3ktkotYW63VGXzTvc9OJSHa yhfuDPQY3eYIxEDQ6VKT+7nfgAsVulc+J2d/2eoRCmylDVX/HCrt0stKT/wfYih0hT9E uQLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=TMN+SqXsYo3d//MTs5uT9QiA8HmOLnYDXkfcKG4wEW0=; b=MOAFtYiTAhP9Ma3f82y3f5LSz3KWODXfEkt357ZX2hbttlsx2WENZTfUMGrrmyjnjQ KaIEwYnl6LD8ih05of3rmgXpHN/gdeAXyJQylgTVsvwBopOSoWRsfSO1NzneNdrSZI65 2ZFX0YRotl+9sAH2DOYwV1c++G47z2LbxgEveH+9j/iNvNGc6BkPqdmYfuiZ+6waBpnA XdQ21FBdnx++LtY91qJjpH7rsopkkn9ljoljN1a0QzkVWrPcUTl/2HZz0y5QfcGprxMJ ePMN4YZt/SIuy+B89l4CaLcszSTGZkbG7XNADuKizhEfQ9BAys3sMDzngvfFAB8f9MhO NTng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TbhaCiBa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h12-20020a056a001a4c00b004fb83b0732dsi16433003pfv.323.2022.04.25.02.21.50; Mon, 25 Apr 2022 02:22:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TbhaCiBa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241448AbiDYHyd (ORCPT + 99 others); Mon, 25 Apr 2022 03:54:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241506AbiDYHww (ORCPT ); Mon, 25 Apr 2022 03:52:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C0BA2113 for ; Mon, 25 Apr 2022 00:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650872987; 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=TMN+SqXsYo3d//MTs5uT9QiA8HmOLnYDXkfcKG4wEW0=; b=TbhaCiBaF9AI+T98PJCpx3PSJK5do5TcxE744+jrhiFVumzjdmrCRo2/Vk8LKYutC3rXIS NmTTeoUU4oiIWtj7C0w5BD29+bWJA/YHmFFJPbsDHGQk6+/ZZ0dq6iE6Qa43soNkyiiFSb V0XeKbcem+SMVejshZgoMA2Qmpyp6eQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-119-KHfZ2AkNMSK6h0TDdzmzOw-1; Mon, 25 Apr 2022 03:49:46 -0400 X-MC-Unique: KHfZ2AkNMSK6h0TDdzmzOw-1 Received: by mail-wr1-f70.google.com with SMTP id n17-20020adfc611000000b0020a7e397ccaso3033011wrg.23 for ; Mon, 25 Apr 2022 00:49:46 -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=TMN+SqXsYo3d//MTs5uT9QiA8HmOLnYDXkfcKG4wEW0=; b=NoznD0kFFXRbkOpvkY1ueJNitl8NEArVmcHj3V88dF7gbZ2HYUZ3lBDdpaerTyo0kn 8DSVYee6aiXTxpa1Ds0Ka73KuWdMxaOl+QoNREzgunet1skq8MWfGuPvz67FYURBCv8O jaKi5LwQr8aCtiMTsO8BczZTsvILn+GcWzGi7hsajJQo1oNYoPCHfYVYepYdT7QG4ajG etNN+WhBdNVMmloZ28Sgpsk20u3GQTr3tZqoT3lx8RyKZijYn1S42DcDNZ5QtdWeVzOp r0fuqu/ivBxjfcgnTC9fGr6jgjTvaXm2NiWPAzGab5wLBTyYlCmN2Uf+byb2Sux9Jl4h noEw== X-Gm-Message-State: AOAM533h2QXKRv9cqP5fJwxb0xh69ETJWwBgCZntKBQsEFBPxlkYer1k btIyBuqKHQ3QJ7FGgRyk921YeNC/FF6MN7ydox3SPUiCGTMhTZ70Vvg6bx2wXCmD6KV+m5w1vRi nwL6yvSQpDAVjnFAozFrmzlZe X-Received: by 2002:a05:600c:350f:b0:393:ec06:4262 with SMTP id h15-20020a05600c350f00b00393ec064262mr3417383wmq.165.1650872985017; Mon, 25 Apr 2022 00:49:45 -0700 (PDT) X-Received: by 2002:a05:600c:350f:b0:393:ec06:4262 with SMTP id h15-20020a05600c350f00b00393ec064262mr3417358wmq.165.1650872984803; Mon, 25 Apr 2022 00:49:44 -0700 (PDT) Received: from ?IPV6:2003:cb:c700:fc00:490d:ed6a:8b22:223a? (p200300cbc700fc00490ded6a8b22223a.dip0.t-ipconnect.de. [2003:cb:c700:fc00:490d:ed6a:8b22:223a]) by smtp.gmail.com with ESMTPSA id s10-20020adf978a000000b0020ae0154f1esm373753wrb.5.2022.04.25.00.49.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 00:49:44 -0700 (PDT) Message-ID: Date: Mon, 25 Apr 2022 09:49:43 +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 v3 1/3] mm/swapfile: unuse_pte can map random data if swap read fails Content-Language: en-US To: "ying.huang@intel.com" , 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, naoya.horiguchi@nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220424091105.48374-1-linmiaohe@huawei.com> <20220424091105.48374-2-linmiaohe@huawei.com> <8aeebc2f0b2a251d3d70402cd0edf063ba911013.camel@intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <8aeebc2f0b2a251d3d70402cd0edf063ba911013.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25.04.22 09:41, ying.huang@intel.com wrote: > Hi, Miaohe, > > On Sun, 2022-04-24 at 17:11 +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. 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 >> Acked-by: David Hildenbrand >> --- >>  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 5553189d0215..b82c196d8867 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 SWP_SWAPIN_ERROR_NUM 1 >> +#define SWP_SWAPIN_ERROR (MAX_SWAPFILES + SWP_HWPOISON_NUM + \ >> + SWP_MIGRATION_NUM + SWP_DEVICE_NUM + \ >> + SWP_PTE_MARKER_NUM) >> >> > > It appears wasteful to use another swap device number. Do we really care? We currently use 5 bits for swap types, so we have a total of 32. SWP_HWPOISON_NUM -> 1 SWP_MIGRATION_NUM -> 3 SWP_PTE_MARKER_NUM -> 1 SWP_DEVICE_NUM -> 4 SWP_SWAPIN_ERROR_NUM -> 1 Which would leave us with 32 - 10 = 22 swap devices. IMHO that's plenty for real life scenarios. I'd prefer reworking this when we really run into trouble (and we could think about using more bits for applicable architectures then, for select 64bit architectures it might be fairly easily possible). -- Thanks, David / dhildenb