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 B5ED2CD4853 for ; Wed, 4 Sep 2024 16:59:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 405856B00E4; Wed, 4 Sep 2024 12:59:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38F376B00EE; Wed, 4 Sep 2024 12:59:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E1C76B00EF; Wed, 4 Sep 2024 12:59:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EEF506B00E4 for ; Wed, 4 Sep 2024 12:59:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 699721C3AF8 for ; Wed, 4 Sep 2024 16:59:09 +0000 (UTC) X-FDA: 82527666018.03.D8F1058 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf14.hostedemail.com (Postfix) with ESMTP id 910C4100006 for ; Wed, 4 Sep 2024 16:59:07 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1ppW22VY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725469069; a=rsa-sha256; cv=none; b=XdqSaC82wpL9prJHGERfD99Nv2LOBYAlFWRJy3Uge28VTpElMFzlXU7V6LABuiJ2wJ+K9I ZKqPnLciuTXF8wugrVZU5EpxqOI66IBRMKiJVpIOh0KG9ON7QAw2ph+T9LZw6RvGdGhFv2 6wcERMyxskapZcEvbQsxF82ZkzKs7Vk= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1ppW22VY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725469069; 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=v1CB9ImWnBS09j2TzKRaEV5BswHxsHTE4CMEUnt0+yw=; b=kx6Eb0gKwxmevYqCH1oSczHR0EsU3uFMboNKeL+lGnAGlbIAInsKjHPiMUqhTfVnMcqU2K 2bMWCnvSHBM0YKsobFA0PLEu5FWhOPL8wowA+rFR/ANYF4WkuqKdS6pw9RMbDWP5HDyOMw CqotmtIxpm1HHs9b6Q9fQfJ/GQSpFTQ= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5c247dd0899so335a12.1 for ; Wed, 04 Sep 2024 09:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725469146; x=1726073946; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=v1CB9ImWnBS09j2TzKRaEV5BswHxsHTE4CMEUnt0+yw=; b=1ppW22VYzbotyX+oQXp2GopnVAMDDil6NiRWrAYdiXca5ZjJx6qb1uXfpL4t5oYGGP m/nzGf8rqHILc9lEL/7/VanGhwQH8FVSWKIU+NN2m1TvSUe4aoSk6kwITlfSXFNBeWm+ 51QS6WQHTWE7R8Cp76/TIsbntS31N2NbKIr5pFTy79c/5qcMWyQpBLq+wBTQPzjkgj5P 51oqgMWaCJZO/DeW8zcUPdOQJmsxo/rnaNB/Z3DO2DIzczcc5Lic0rPsUadQPkK/3yZv DrygWaeDewtuZX0UBFZ2Wku7ePUSUnee+8GyCyywt/300QhtZlbY1LnDUsoLg9ZEScX0 NgnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725469146; x=1726073946; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v1CB9ImWnBS09j2TzKRaEV5BswHxsHTE4CMEUnt0+yw=; b=EiMIcoLU0vOsPe3hV/aFrSSjj18VxJ/cpw4zaGGiCew9i+r3HdrF312MEqcIWOB2bQ RaTKVlZ8uNxYYJjPNoNII2OY4vCmSOxHqYV8pxnP96J0Idy4sCSTshFG6zuWAwHjmWFM ErbprGNLSlxCadWhufSpBt6lJ490tOvpwuYqCwANpkjpTeR3CNiT8UyMylhMtJ7t9j2c i1h6fo/k6EsgJ5f5YyNO6mscHLJ7uUtWyVNId27TpkC95JrQZBd5tP9+fbBX8nDNpEV6 jrF4kzIlmVAPnylQvpD3BCa7jYb7uatQ8Xh6ACGR6If0jSDxUKNBXN8X0iOxW5sDk4N1 calg== X-Forwarded-Encrypted: i=1; AJvYcCXhg1ooVKf16RYxesRn016vo4IdwAfft0xFfAqRWnrVn1YfyRB3a6Eg7BNekPJrxIkpsGPblmd/7A==@kvack.org X-Gm-Message-State: AOJu0Yzx8zNdhrKadRtMcUqXeCLey3cWudYFP3WD5b1mpxTwDGDJe+AG CXnauzIGVz8fxQ0peNeklesgGVcqhrLns6IGDqLlfFfbFL45ZwFEYUyNZERqeSt8eyJDD//z1WX payjZaPr2OeqoyDLIZcesS7K36k7ktdi4aely X-Google-Smtp-Source: AGHT+IG0aERy7faC+1a6oZmkUUhuQ4K85jcFSSvvPHiUncBSURkpbe0WpQYOSgoRnbA5jZ9RY4ycgAXL88BusZEB1Ro= X-Received: by 2002:a05:6402:1c86:b0:5c3:c2fc:8de6 with SMTP id 4fb4d7f45d1cf-5c3c2fc98ddmr144634a12.3.1725469145666; Wed, 04 Sep 2024 09:59:05 -0700 (PDT) MIME-Version: 1.0 References: <20240826204353.2228736-1-peterx@redhat.com> <20240828142422.GU3773488@nvidia.com> <20240828234958.GE3773488@nvidia.com> <20240904155203.GJ3915968@nvidia.com> <20240904164324.GO3915968@nvidia.com> In-Reply-To: <20240904164324.GO3915968@nvidia.com> From: Jiaqi Yan Date: Wed, 4 Sep 2024 09:58:54 -0700 Message-ID: Subject: Re: [PATCH v2 00/19] mm: Support huge pfnmaps To: Jason Gunthorpe Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Gavin Shan , Catalin Marinas , x86@kernel.org, Ingo Molnar , Andrew Morton , Paolo Bonzini , Dave Hansen , Thomas Gleixner , Alistair Popple , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sean Christopherson , Oscar Salvador , Borislav Petkov , Zi Yan , Axel Rasmussen , David Hildenbrand , Yan Zhao , Will Deacon , Kefeng Wang , Alex Williamson , ankita@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 910C4100006 X-Stat-Signature: duhg18ccxywgica5tshfi3ugtm4xbgck X-Rspam-User: X-HE-Tag: 1725469147-421245 X-HE-Meta: U2FsdGVkX19cy+Qze6XygA9ad4JEA4Jb3soke0wQAmtskDlrTi5bdhkqXaKE8XxHMLDj1Vlbx4MCvLrJvMQQZU7W9Mnk5/rBrFLzKteiUszfggs3BAHNq+Yn9NSZzWAkW/GMnPNmche6m7KBGXtgvA1mrBXY/hDPiCPdXxxqZ5kkn9JsT+KSVOXqJ3VHIdBL3jmj19UEkOz/XEZUn8AOHkP3SlMHIAxBOQAVhmxiseHBo8bawF/aOhVmzMYx4NgSyvdU2ZD+smCUj4NtkDD6zsPT/DWqM1uStg2QVC6L3Kp4jZDmL1v80nm/QqT+2eQLSZU4y/Duck7u3TfPkh/abrrXEtKxi8e0yKFZdgPYfgTT9kTFCF1CIGjdNq7Froc5u4py1jxJhw6/9HXzgzh/9aGu7P5XxJeU0zWDnDG0R8u4sArZySoXXiOmxKnT1lKDsarvInJg+rG1EColmo2VQBmxz9Ig+iRn+LKxauUCy/JN4gdinEa9Bp/JQ7NSxD3QrOQDXx/iayKsQoY8z9+n9lcu3hzcIyPcu2O+j8BI/f2Nw33CjemmhggOHLN5R39qU025UOHQwkUXiyLFwzEOSJ266zDVcqaidg0dk7c/AcVwo+tGApXzsziT3eYiIByKBIVOzTgmZtEMOOQaJC/k28LLIQKdHCyLpxGCXZEccXABwYbDAUWAnWc72rOtMeJtDZQuuydvBcrnVjGtp6h2siejbtuL7j3vO5W+eb+UTxbGpTvlypbBtsq7cbC+XG33DhR+ZtpK/ysWmhWsVqNRXmGNXRHY3XLZvXmu+O0oCHocb7Uad4KqlTdTvdb2sQ40wiCPAkmav0NthcEz8CA+nVEh8m5gyiFgVkuuRz34Pfb9UUjqf6WklXbz1cgSHJXBeN5LXHoL1i0N3gHvKiGHv8aUL6nx8MfZZd2d8rdY59CLc1w3lan36CtV5debhp8IzsSd9mLvI1s6mArWvTX BSPPhpq5 86QD3vEpXxtMj4SdWs6WJFZN9vmOL3UdmB/DZD4QznVyVXD3W4SfpFmtX2zdrkVdAtH0PnX+y8Yqz6vsfwkXp3K6gIpHo+r2539PLRvSCNsZaT1UY4AlU3iw+R1/lqxiAmO43Z1TBe0CsnifPlwN7pLouuidoVhj/I+vws5Ws0tiB+u/9k7CSZZ6ZAebDTUt0OElJcKkPDp6K6dIdZZVtTpHq6ZlVXFij030I 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: List-Subscribe: List-Unsubscribe: On Wed, Sep 4, 2024 at 9:43=E2=80=AFAM Jason Gunthorpe wro= te: > > On Wed, Sep 04, 2024 at 09:38:22AM -0700, Jiaqi Yan wrote: > > On Wed, Sep 4, 2024 at 8:52=E2=80=AFAM Jason Gunthorpe = wrote: > > > > > > On Thu, Aug 29, 2024 at 12:21:39PM -0700, Jiaqi Yan wrote: > > > > > > > I think we still want to attempt to SIGBUS userspace, regardless of > > > > doing unmap_mapping_range or not. > > > > > > IMHO we need to eliminate this path if we actually want to keep thing= s > > > mapped. > > > > > > There is no way to generate the SIGBUS without poking a 4k hole in th= e > > > 1G page, as only that 4k should get SIGBUS, every other byte of the 1= G > > > is clean. > > > > Ah, sorry I wasn't clear. The SIGBUS will be only for poisoned PFN; > > clean PFNs under the same PUD/PMD for sure don't need any SIGBUS, > > which is the whole purpose of not unmapping. > > You can't get a SIGBUS if the things are still mapped. This is why the > SIGBUS flow requires poking a non-present hole around the poisoned > memory. > > So keeping things mapped at 1G also means giving up on SIGBUS. SIGBUS during page fault is definitely impossible when memory is still mapped, but the platform still MCE or SEA in case of poison consumption, right? So I wanted to propose new code to SIGBUS (either BUS_MCEERR_AR or BUS_OBJERR) as long as the platform notifies the kernel in the synchronous poison consumption context, e.g. MCE on X86 and SEA on ARM64. > > Jason