Received-SPF: pass (google.com: domain of linux-kernel+bounces-134106-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: "Luck, Tony" <tony.luck@intel.com>
To: Oscar Salvador <osalvador@suse.de>
CC: David Hildenbrand <david@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Yazen Ghannam <yazen.ghannam@amd.com>, Miaohe Lin <linmiaohe@huawei.com>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>, "linux-mm@kvack.org"
	<linux-mm@kvack.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: RE: Machine check recovery broken in v6.9-rc1
Thread-Topic: Machine check recovery broken in v6.9-rc1
Thread-Index: AQHahymLPB0TDn1nE027XBXiiAzj6bFZxGewgADPMSmAAApqgIAABVuAgAFIWAA=
Date: Sun, 7 Apr 2024 00:08:30 +0000
Message-ID: <SJ1PR11MB608323D7E6113B78A35F4999FC012@SJ1PR11MB6083.namprd11.prod.outlook.com>
References: <Zg8kLSl2yAlA3o5D@agluck-desk3>
 <1e943439-6044-4aa4-8c41-747e9e4dca27@redhat.com>
 <SJ1PR11MB6083AB3E55B7DE0D3FBE185EFC032@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <ZhCQPwgMWo9w3LlO@agluck-desk3> <ZhCxAZy-Iuz2XR7A@localhost.localdomain>
 <ZhDHh_W1WZuFhsfg@localhost.localdomain>
 <ZhDMBZ2I9M72D87F@localhost.localdomain>
In-Reply-To: <ZhDMBZ2I9M72D87F@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2YcjvS0uk8uf/eRWTPrJT3GDiA5kwsJSwzEvFyxJvBm4jfcfqwB88rVETMo/?=
 =?us-ascii?Q?FFiaGefUu5ZeB2/E/7/WjsNzymwhgk3Mej06EWUVmWPaby4ni8ajx2ytZGnI?=
 =?us-ascii?Q?+bqYDeVucLjLBoBeqY1TlEuHNcC0nEoPs4A7aE2hyXmd7WvU6BIVMnpBOaw7?=
 =?us-ascii?Q?uj2KLNGLZstjlFUF7UC7YIA8vF4pHGFbzvSERFL0CwLUzJXy9xaZwMsPLxEB?=
 =?us-ascii?Q?BeXn8pP7oeWdttzUzjgJ5cQcEyUVXsmB8a23bMAzUscJlZaQCJdnmRAJFdG2?=
 =?us-ascii?Q?a0wz7eTUmCVzO4vmbtGtXFYOhcYQfcs0VbKU1vOMvdXMAAsgSmesx/HZ5ffC?=
 =?us-ascii?Q?VUku4sAaz0SnSalVnV+3olNIZSb/KVLal0QY/rNoGUj74f1/Vn8EuHdsbFuA?=
 =?us-ascii?Q?s5SeeEKiMzo1EtNYMdE9CnGmSDBnKLRW7cBTzPuh6TmSoRP/90YAi7BEfBU3?=
 =?us-ascii?Q?EMDS3IZTg1A6SyWFrIlAoeDY4ABkvaRiHiDBios7ineMhvy47pX6XP8L5I2n?=
 =?us-ascii?Q?Nqpp1thv9lcKXHLowJFdCR7Qa7qP9RXe+y42MwYNS9DVV0usj0hf9ajnY58K?=
 =?us-ascii?Q?up9KZP4zXxBc+SL1BRE3NQYu5zOsuksAqcIaml2SCRwqRXegwcIAtim2dwOS?=
 =?us-ascii?Q?JhxQp/ST4aZtMOr2x8mbYf7MKyJTXNIiuL7ukd83PVC2P1Ap4FnppG6Xhu2K?=
 =?us-ascii?Q?n5HxQotAuofZ5N0rwBMPHaYljlEROFB/uHRax2ufGg69Exe9Cq+2pNWJZJWR?=
 =?us-ascii?Q?S2uu1HcyYS6yIuKP/161a2ZZQGuTZDO+lxY5AO9VJ6ATscsPd6cKeYb4wui+?=
 =?us-ascii?Q?4f5dFB73QqZH6vGgc8jwzvCFZcNdriiTAecsrmsEqhra1WVWsGmFHPFNOyOR?=
 =?us-ascii?Q?itNVFEWCDSCciDX+X+gyc2iZpdPgVN4bjYMC5p+ZB74msS1HQIqZN9jT1Tb7?=
 =?us-ascii?Q?tVCoYOHDIdRwKmOgAJeVhO8H4TYoDt25iEE8cuP8A40J7en0B5pV/cmRpizQ?=
 =?us-ascii?Q?DZsOd4c/MCH/YDLLwV2iYxsTEZ+db+LR/l/QQTTGxImyHGb7wCu0r4aQejDi?=
 =?us-ascii?Q?2bJow8Zn2dyIDPWz8CnC+aAj8c850XNIeqEVdI4OXl1FBtc8I+lXrVYqlTpU?=
 =?us-ascii?Q?l19cGHFnHei8lNgdOlRXwp0uMuSKct5tahgscR225F/iMRS9DqquarDenUuV?=
 =?us-ascii?Q?ccXzDwGOnmXZTzBe/w3YxMeKdIuJ0Dhkke85lyYZIAoOVRLasm+ASOEYQHjj?=
 =?us-ascii?Q?LyIYse28Zs397d57wC0OvWbvRWkyTR8117Qzg4hXaTxPZ/l79G+GJ06kAFtF?=
 =?us-ascii?Q?9CI+wQaOKWD3VNDZLx5Mg2C067NMqI+l1V6hkurKvVoHytqqV98qyH0yqtnq?=
 =?us-ascii?Q?jGyJQrL1CS8+4PFAeJKkduXRv9xDG/n+k0GGRY07xU69pc+gHSR5JYR6B6FM?=
 =?us-ascii?Q?Go+6BJZIR9gUumsEnv+HwkYUovHjRFIyECmr6weUQBhKh8d7+KcsRoPWqyw4?=
 =?us-ascii?Q?XSRAoP732b4kXH0LGo4vNfaN5qqvBcZSOBh4wMUSO8YKEHstJpy9kNcn4upH?=
 =?us-ascii?Q?1UE9UYMswbA6V9lehWJwUKSuMOYrLxsliUXhi4Ht?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6083.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f809916-03d4-4caf-0e7d-08dc5696dbab
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2024 00:08:31.0140
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: w3aRW5pP491PwNcTlYR1jpoUFKhfxWa1C1SohsQGeOKfm26yTf4QN67vEdqID6gtsBSvaz2SM0ZHkDBNQk484w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6747
X-OriginatorOrg: intel.com

> This one is against 6.1 (previous one was against v6.9-rc2):
> Again, compile tested only

Oscar.

Both the 6.1 and 6.9-rc2 patches make the BUG (and subsequent issues) go aw=
ay.

Here's what's happening.

When the machine check occurs there's a scramble from various subsystems
to report the memory error.

ghes_do_memory_failure() calls memory_failure_queue() which later
calls memory_failure() from a kernel thread. Side note: this happens TWICE
for each error. Not sure yet if this is a BIOS issue logging more than once=
.
or some Linux issues in acpi/apei/ghes.c code.

uc_decode_notifier() [called from a different kernel thread] also calls
do_memory_failure()

Finally kill_me_maybe() [called from task_work on return to the application
when returning from the machine check handler] also calls memory_failure()

do_memory_failure() is somewhat prepared for multiple reports of the same
error. It uses an atomic test and set operation to mark the page as poisone=
d.

First called to report the error does all the real work. Late arrivals take=
 a
shorter path, but may still take some action(s) depending on the "flags"
passed in:

        if (TestSetPageHWPoison(p)) {
                pr_err("%#lx: already hardware poisoned\n", pfn);
                res =3D -EHWPOISON;
                if (flags & MF_ACTION_REQUIRED)
                        res =3D kill_accessing_process(current, pfn, flags)=
;
                if (flags & MF_COUNT_INCREASED)
                        put_page(p);
                goto unlock_mutex;
        }

In this case the last to arrive has MF_ACTION_REQUIRED set, so calls
kill_accessing_process() ... which is in the stack trace that led to the:

   kernel BUG at include/linux/swapops.h:88!

I'm not sure that I fully understand your patch. I guess that it is making =
sure to
handle the case that the page has already been marked as poisoned?


Anyway ... thanks for the quick fix. I hope the above helps write a good
commit message to get this applied and backported to stable.

Tested-by: Tony Luck <tony.luck@intel.com>

-Tony