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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EB61C433F5 for ; Mon, 1 Nov 2021 21:58:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8344E60E98 for ; Mon, 1 Nov 2021 21:57:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8344E60E98 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 18B6994002E; Mon, 1 Nov 2021 17:57:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13BB294002B; Mon, 1 Nov 2021 17:57:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02A5394002E; Mon, 1 Nov 2021 17:57:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id E85D994002B for ; Mon, 1 Nov 2021 17:57:58 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A2F77545DB for ; Mon, 1 Nov 2021 21:57:58 +0000 (UTC) X-FDA: 78761724636.18.E0E09DA Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf23.hostedemail.com (Postfix) with ESMTP id 805FC90000B4 for ; Mon, 1 Nov 2021 21:57:47 +0000 (UTC) Received: by mail-wr1-f50.google.com with SMTP id d3so30241288wrh.8 for ; Mon, 01 Nov 2021 14:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aEHs4l64QFfhys83SS6KvuhdHhIhDBFRgH3vIISnozo=; b=cn0HsL6xg4R/nk6ImcqEgKt0mIhg4j2RYPxIP7gMC7SCf2z9Xwx54FmOTHjG9PoGUs NU/2/xFPA4FV/oHLxZmFxhvaInli1OtFfSk/aghn3q1tTn6rBJT/dqKe7XUnaX07j87Z P1ahk/cu0+PiLYNwVSpNhw6i70SejE4uE2ZpyvGgEpI5klOvne2RX65wtyiHgnPAf9jy XQxURTtIfWrCrCIom069od7zXOnhMKWWDEx/XtJ1uBu751gCB8czUcBjSfIrJerxSP8z z45YNQOGurINMPn7OSU2fAHCYVSAsLlRkakN/HYKjNpp8gjbTwzQjsRsTA2BxM8snPSA Ju6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aEHs4l64QFfhys83SS6KvuhdHhIhDBFRgH3vIISnozo=; b=5q6Qnme/NnB8t6yPY/jH96t4OMr/DjqKgOdJg4SbC1ez4gP2zHZoJB/sZArUZYnlCZ HchivtPmGB50LLYZeDmWOUwhDN6dllsXvnzarVzKfgQcintfNGPoVCK7ipFOpPft4s72 rubGK4VfLnK7TEpJeP8DyDG4vVMcWWYCLzzn6aZ6SgXiWRwq2UUFlDsJcFnglLvpA1Te Y1NNJyF4LvH2KkUJoCGVhAnIgc8vneE+ZGZ+YuOJgx+bbjbdbX0y/qwebI0tc4lzQAhm c6N0Nk13ls2ehLbVgYJuJiuwTQM33pvKbYQ+RslWwLUbT6NMpdpzkNoByiwfSLw6VBIV 04ZA== X-Gm-Message-State: AOAM532ywV+0CXhxKLUAi05fB/GTe4urHcIhHp0GhfmwToMIv6LAq2T2 15IBQUr0fweBxwbhieeYob1wA1xVN0OGsL64kuRGjw== X-Google-Smtp-Source: ABdhPJwyLxnOCkzkBr/ZwoA0HO+6+x1jIDObsW9eD1Rbio1CTJvMbujy31dl65pPxh2agrQRS3r6sPPJ1GepY1nm4z4= X-Received: by 2002:a5d:65c7:: with SMTP id e7mr22076054wrw.319.1635803876873; Mon, 01 Nov 2021 14:57:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jue Wang Date: Mon, 1 Nov 2021 14:57:45 -0700 Message-ID: Subject: Re: [v5 PATCH 6/6] mm: hwpoison: handle non-anonymous THP correctly To: Yang Shi Cc: Hugh Dickins , Andrew Morton , "Kirill A. Shutemov" , Linux FS-devel Mailing List , LKML , Linux MM , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Oscar Salvador , Peter Xu , Matthew Wilcox Content-Type: multipart/alternative; boundary="0000000000000173ed05cfc1453e" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 805FC90000B4 X-Stat-Signature: km75f9w993z6pj6zdtrkurx5yqsdekia Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cn0HsL6x; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of juew@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=juew@google.com X-HE-Tag: 1635803867-834754 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: --0000000000000173ed05cfc1453e Content-Type: text/plain; charset="UTF-8" On Mon, Nov 1, 2021 at 1:11 PM Yang Shi wrote: > On Mon, Nov 1, 2021 at 12:38 PM Jue Wang wrote: > > > > A related bug but whose fix may belong to a separate series: > > > > split_huge_page fails when invoked concurrently on the same THP page. > > > > It's possible that multiple memory errors on the same THP get consumed > > by multiple threads and come down to split_huge_page path easily. > > Yeah, I think it should be a known problem since the very beginning. > The THP split requires to pin the page and does check if the refcount > is expected or not and freezes the refcount if it is expected. So if > two concurrent paths try to split the same THP, one will fail due to > the pin from the other path, but the other one will succeed. > The failed thread will result in a -EBUSY from memory_failure and SIGBUS sent to the process without context (address, BUS_MCEERR_AR). This is undesirable for applications who intend to recover from memory errors. One possible fix is to recognize such cases and signal properly from memory_failure. > > I don't think of a better way to remediate it other than retrying from > the very start off the top of my head. We can't simply check if it is > still a THP or not since THP split will just move the refcount pin to > the poisoned subpage so the retry path will lose the refcount for its > poisoned subpage. > > Did you run into this problem on any real production environment? Or > it is just a artificial test case? I'm wondering if the extra > complexity is worth or not. > This can be easily reproduced in artificial test cases. I'd not surprised if production environment hits this bug. > > > > > Thanks, > > -Jue > --0000000000000173ed05cfc1453e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 1, 2021 at 1:11 PM Yang S= hi <shy828301@gmail.com> w= rote:
On Mon, No= v 1, 2021 at 12:38 PM Jue Wang <juew@google.com> wrote:
>
> A related bug but whose fix may belong to a separate series:
>
> split_huge_page fails when invoked concurrently on the same THP page.<= br> >
> It's possible that multiple memory errors on the same THP get cons= umed
> by multiple threads and come down to split_huge_page path easily.

Yeah, I think it should be a known problem since the very beginning.
The THP split requires to pin the page and does check if the refcount
is expected or not and freezes the refcount if it is expected. So if
two concurrent paths try to split the same THP, one will fail due to
the pin from the other path, but the other one will succeed.

The failed thread will result in a -EBUSY from memory= _failure and
SIGBUS sent to the process without context (address,= BUS_MCEERR_AR).

This is undesirable for applicati= ons who intend to recover from memory
errors.=C2=A0
One possible fix is to recognize such cases and signal properly= from
memory_failure.

I don't think of a better way to remediate it other than retrying from<= br> the very start off the top of my head. We can't simply check if it is still a THP or not since THP split will just move the refcount pin to
the poisoned subpage so the retry path will lose the refcount for its
poisoned subpage.

Did you run into this problem on any real production environment? Or
it is just a artificial test case? I'm wondering if the extra
complexity is worth or not.

This can be= easily reproduced in artificial test cases.

I'= ;d not surprised if production environment hits this bug.

>
> Thanks,
> -Jue
--0000000000000173ed05cfc1453e--