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 026F4C4332F for ; Thu, 8 Dec 2022 08:41:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 610068E0003; Thu, 8 Dec 2022 03:41:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BFCA8E0001; Thu, 8 Dec 2022 03:41:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48A618E0003; Thu, 8 Dec 2022 03:41:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 37C6D8E0001 for ; Thu, 8 Dec 2022 03:41:52 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1142716035B for ; Thu, 8 Dec 2022 08:41:52 +0000 (UTC) X-FDA: 80218496064.10.5981258 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id D740EA0002 for ; Thu, 8 Dec 2022 08:41:48 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PKGipOrd; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670488909; a=rsa-sha256; cv=none; b=P1hEytnthVyZypDhM1vrIo+O+qjs+w6aov8wX49uf8U+Zvs586FmKL7XagCqFOyvI4YU5o 9Gb9SwQZgjnUXgM+gvQYIAfNzdsVHTDngmzN5rQUGavEjSDu8BwA4j30UK9MjkcTjS/fO0 volKtLrNZd9nJLXnp+120LOyuZxk9WU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PKGipOrd; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670488909; h=from:from:sender: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:dkim-signature; bh=wUElgt1lp4nGY3sTMyIIkCMUOHZcBXcdQIFg7HKHvUg=; b=Gzg3u4BNBm7FdkCI8M1YyK3r1wilvJhHCU/HpD9f5kCnm83K8baALP2V7A2qtM+gh7YKlB /GQuk5S+R+eWy9a4SXxzfCqwOvDFpMrYbQ+iwh+ok+WFzZA0SCaHiBoTTltZUj+ip+DpaG yQdE9Z9BE4tOpHWfvQEfiTt34hClEHc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670488908; 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=wUElgt1lp4nGY3sTMyIIkCMUOHZcBXcdQIFg7HKHvUg=; b=PKGipOrdf+rNTCIOexfLtTijuzkjKyYLamJ/TGGrbRHWSwti2c0XaNaPTYc76IWJgtEQvn YaRYyyUPtqxxofJvnzbx24VL0wM7BtYyyvCC2qgIpAAu0svR0rTNTRRCcL7rx8s/pBVdB2 e6qE2i71KVc0bVzh81zvQ1sQbR33vco= 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.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-606-g-vaNxsFMgW0geTtfL4Geg-1; Thu, 08 Dec 2022 03:41:46 -0500 X-MC-Unique: g-vaNxsFMgW0geTtfL4Geg-1 Received: by mail-wm1-f71.google.com with SMTP id r67-20020a1c4446000000b003d09b0fbf54so2099819wma.3 for ; Thu, 08 Dec 2022 00:41:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wUElgt1lp4nGY3sTMyIIkCMUOHZcBXcdQIFg7HKHvUg=; b=UgCrgHzlTMBJy0Y6hWPp+EPxBV/r3FN6PklV0pnzTXIPQTKQ6U2Tgh2pFlNKHkL4st GlSyO7P4jz+ycdNDLm7mEG1gfv9S1MLWUlHySoHoGZ6X0to6EskDTBOGaBWtUqylB9i7 M0zRUksRXZP/DH8MLiHLspxA26Y8UkwiPlGxNPsLjwx42lPJYqhYHUKPMDqNYyBYK9lz gEseV9e4TcoC4Fu/2z8Z2LwKq5iEepd4f5htJU2MdPTbi9ZPV6I3eWsaB4vT7GaTy6d4 kG8R4xsk3XNRe4qG6F9EsWjltLokdpXcM8PL+GcMdY8soT2BhpM026eRI9JVUZ/O4A+S 6FFg== X-Gm-Message-State: ANoB5pnCadeHdFJgvd0PQap6AVga04WOS38uOmQxLf7OTsnOJbnLk+xe ylPZL9WzA7YOHzB9LNlGmTNuT23Ony4vz6oqnKKOWhu/WUQmLmIy1MQHhq+e2RUJtiTKD6Ut7sa yaPu10TtRalk= X-Received: by 2002:adf:dbcd:0:b0:242:1294:5174 with SMTP id e13-20020adfdbcd000000b0024212945174mr30087112wrj.249.1670488905413; Thu, 08 Dec 2022 00:41:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf6AXinO8jvwIeLd86MpEyy2fCHsv8sw9X6QpQm+7NAbamPG02zau6AYIEprMxYwXnYwE+cF8g== X-Received: by 2002:adf:dbcd:0:b0:242:1294:5174 with SMTP id e13-20020adfdbcd000000b0024212945174mr30087105wrj.249.1670488905092; Thu, 08 Dec 2022 00:41:45 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id e14-20020adff34e000000b0024228b0b932sm26387172wrp.27.2022.12.08.00.41.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Dec 2022 00:41:44 -0800 (PST) Message-ID: Date: Thu, 8 Dec 2022 09:41:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2] mm/swap: fix SWP_PFN_BITS with CONFIG_PHYS_ADDR_T_64BIT on 32bit To: Yang Shi Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Peter Xu , Hugh Dickins , Andrea Arcangeli References: <20221206105737.69478-1-david@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D740EA0002 X-Stat-Signature: rdw4bh61u9mmnk6q48g8gmnqd6ubwxin X-HE-Tag: 1670488908-185194 X-HE-Meta: U2FsdGVkX1/nJOV33bpUEJti3DnnaBnFFHGEx70vOMQNawXgwVCoZ21mQhLIkCQL61RuAzu9KJznBQYT4xFOOmjcu4133C3wT7w6Jvwhez4YiW0jrmU23LGzBisv8LjvYsQedIRKXMBP5NHN4zI4QaCdcNQooMh/Ix/y758M/dEYl2tfZ6JZvWoLOdpD9wQikvMX6OKcJs6XufZDgTRTAVFM6dAfs3Wnw/a7w42fT8Iz0pU9NXrMH7LO2BJPaNuh3rGU7YFsDGh1s9OcSmwlW+LEvghg013BXGliZcjrA7/f/VH3mcknsA5Ay7eHfVmDFQFbaktic2k+5CHSKP/FZgF4qT1bzzV7cPzhshhwiMkD1pAJisGE24wNNNRT2dv8EdhjNvikpTkkkMvbtQlOnM0RFsP805zo6iC/JZn0N4lYilY0C3XAp8s5yDsRpk5DTE2sZRdaHruoPyAh+C9N7zV9mCpYmGC6UFtK9ULLmyyJCkcwp/sbvILlOV80w0h0y8JX1er7RYBEk5b66mW5NU6mRU84SBPWjELbpWF1/Sn8Uw6K63FxAGy5kxaGwLFoOWUgYFdVWy5AVD+PE+N92eHl9E4/fxov6Ay5df1QKh1/+SC0NQLKOr29IA96gDpa9PiufeimHCOZPb1a7ZS+Rs7Jr0Kff5kn/blBEgvO26TT/wltxGEtxFtRqw3fk066yAvkouCxxy5U/q2Ad9hcadmgUJ3eL5HC7PI8multRPr9jq58kCUQ+7T6GhsRymUf7v6rY7CCYtP5nRvF4ETMlpAAdt98D41mlarpN2AOugbsGGG8e5+/M3yyMDDWYw3W+w7TZXt7czN4EUERpS3jSz2kHf4yQUEGjuRZi7c2dwdeM6QZmIFVWMJMGeTiv8FoI5rLFJwoXCdiSbBR5PkbktMsD1j2aLie9ADJqiOh1Syzz8YYQT+Ow8wdrnTRubOatJJTevy8Ls98uNKMuHM 3ccahkGY DZdoWdPOCvvW7bgwNgQhpvOf1ZIZ05kkhy5gqC0EJ2B6tq/lM+Dcv8VF8MyamRdLo0t5ZYDYbqM1xO4yaRdjYAhVuK1DniuGNEoebf7VM2sDH1ODc9o8JM+fzLxqexXWX1In6XL9b3Z+xJEk5aq87iGvgBRsLkn2EGzibRtpd3BrLSpX0UMrwug3kLaLHzRfPRZzW 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 07.12.22 23:40, Yang Shi wrote: > On Tue, Dec 6, 2022 at 2:57 AM David Hildenbrand wrote: >> >> We use "unsigned long" to store a PFN in the kernel and phys_addr_t to >> store a physical address. >> >> On a 64bit system, both are 64bit wide. However, on a 32bit system, the >> latter might be 64bit wide. This is, for example, the case on x86 with >> PAE: phys_addr_t and PTEs are 64bit wide, while "unsigned long" only >> spans 32bit. >> >> The current definition of SWP_PFN_BITS without MAX_PHYSMEM_BITS misses >> that case, and assumes that the maximum PFN is limited by an 32bit >> phys_addr_t. This implies, that SWP_PFN_BITS will currently only be able to >> cover 4 GiB - 1 on any 32bit system with 4k page size, which is wrong. > > Thanks for debugging this. IIUC this means even swap is actually > broken on x86_32 + PAE? I saw all different kinds of issues while testing debugging without this patch, but they might just be a fallout from previous page migration/THP splitting issues. I think swap should be fine, because SWP_PFN_BITS only affects swp_offset_pfn(): only used when is_pfn_swap_entry()==true. Thanks! -- Thanks, David / dhildenb