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 4E0A4C433EF for ; Mon, 25 Apr 2022 07:49:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B79CB8D0012; Mon, 25 Apr 2022 03:49:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B299D8D0006; Mon, 25 Apr 2022 03:49:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F28B8D0012; Mon, 25 Apr 2022 03:49:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 9182F8D0006 for ; Mon, 25 Apr 2022 03:49:50 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5C0CA227D1 for ; Mon, 25 Apr 2022 07:49:50 +0000 (UTC) X-FDA: 79394627340.08.0086024 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 096D440037 for ; Mon, 25 Apr 2022 07:49:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650872989; 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=UcU0hvsNJqYoSIuU3Qkn2CjFyzoNqZRAQgjsqWlFje8XxhnkjzwpAXf6kzrIiRkGJ+AsId fclUW3WlyM1vTJ7FVjNUjQxML+gS9uRBh6fWv6EQarLWS5n/jDBwUok1ni4Hi5GyPlMPl1 /rzsfnobromJFUE94U0dbcl9K4auCIU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-623-qVtnWqs-O0yPXVQQ1jJEPw-1; Mon, 25 Apr 2022 03:49:46 -0400 X-MC-Unique: qVtnWqs-O0yPXVQQ1jJEPw-1 Received: by mail-wm1-f71.google.com with SMTP id c62-20020a1c3541000000b0038ec265155fso9919996wma.6 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=Axai6CZjfY5ajbwqFwldmnZsA6gepyRwqSvr7mv6h0XRyD1TDZ5411SxJGsEuuAvxR LZTdaroT4wyWwl7e753sIOS2/+jKxtfks12POHDla7sskLstPL2Xc5xyAUQGl2G4RNbi 1WvFnWUmRQrr/Cwq9l3zRauPQYwzKDmmSJobjQVzRkNQoavHXwbJZsxvQ/mC63pyopmu W3xkOBmOt4EZ6KnOJR51B+HeNBRypfdVISDL5qKe8XM9ujqFnf7HOUBuKZrOquU3wzdE 6d2nU7u7f6yzxX+asAhI8b519qf01wkYFpU5BrlpmbKjSg2/GRwYjPfWHkQmY8Az64oo Pt8g== X-Gm-Message-State: AOAM533ohCM9G+hYVoJpdQCs05yECp5YAgQ0MEKEChuHXSHxAbU8R8p3 fqmAKUZt/BR1Y4+VKiuAYZmNLWOzYLIplvEEw7nBLJlQOnJ4d08OIWZnmtD7PJEZ8zGlBsE84O8 geGl262SsOa4= X-Received: by 2002:a05:600c:350f:b0:393:ec06:4262 with SMTP id h15-20020a05600c350f00b00393ec064262mr3417375wmq.165.1650872985014; Mon, 25 Apr 2022 00:49:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxQO8+qq0D++pW4n/MjMu77yOzpy/8PzYibDLgHNPuYQDzKI0pe3hNoGJFI6KjwOY0rJrejg== 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 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> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: zgfsfjtukqu7sz1ncfmbye8um5yzdf5s X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 096D440037 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UcU0hvsN; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1650872983-410583 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 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