Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   =?iso-2022-jp?B?SE9SSUdVQ0hJIE5BT1lBKBskQktZOH0hIUQ+TGkbKEIp?= 
        <naoya.horiguchi@nec.com>
To:     Dmitry Yakunin <zeil@yandex-team.ru>
CC:     "osalvador@suse.de" <osalvador@suse.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "mhocko@kernel.org" <mhocko@kernel.org>,
        "mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
        "n-horiguchi@ah.jp.nec.com" <n-horiguchi@ah.jp.nec.com>,
        "max7255@yandex-team.ru" <max7255@yandex-team.ru>
Subject: Re: [RFC PATCH v2 00/16] Hwpoison rework {hard,soft}-offline
Thread-Topic: [RFC PATCH v2 00/16] Hwpoison rework {hard,soft}-offline
Thread-Index: AQHWQA+H5/eI9wztJka38makXyA1EqjZOdWA
Date:   Mon, 15 Jun 2020 06:19:53 +0000
Message-ID: <20200615061951.GA26108@hori.linux.bs1.fc.nec.co.jp>
References: <20191017142123.24245-1-osalvador@suse.de>
 <20200611164319.16860-1-zeil@yandex-team.ru>
In-Reply-To: <20200611164319.16860-1-zeil@yandex-team.ru>
Accept-Language: ja-JP, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <2FE0E49E76F0E04699B62B358E37EF69@jpnprd01.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a8f3857-0fbf-44fd-aef2-08d810f41e5d
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 06:19:53.9606
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e67df547-9d0d-4f4d-9161-51c6ed1f7d11
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tRpXFBhW8W7MUt6bKwVTmFy+JBP3la7Hb6I5JOXfWqgXjq+Kc3s5OzaoS0cBMuH9UW5EgJTwO4t4LO1keX+aqQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2540
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Dmitry,

On Thu, Jun 11, 2020 at 07:43:19PM +0300, Dmitry Yakunin wrote:
> Hello!
>=20
> We are faced with similar problems with hwpoisoned pages
> on one of our production clusters after kernel update to stable 4.19.
> Application that does a lot of memory allocations sometimes caught SIGBUS=
 signal
> with message in dmesg about hardware memory corruption fault.
> In kernel and mce logs we saw messages about soft offlining pages with
> correctable errors. Those events always had happened before application
> was killed. This is not the behavior we expect. We want our application t=
o
> continue working on a smaller set of available pages in the system.
>=20
> This issue is difficult to reproduce, but we suppose that the reason for =
such
> behavior is that compaction does not check for page poisonness while proc=
essing
> free pages, so as a result valid userspace data gets migrated to bad page=
s.
> We wrote the simple test:
>   - soft offline first 4 pages in every 64 continuous pages in ZONE_NORMA=
L
>     through writing pfn to /sys/devices/system/memory/soft_offline_page
>   - force compaction by echo 1 >> /proc/sys/vm/compact_memory
> Without this patch series after these steps bash became unusable
> and every attempt to run any command leads to SIGBUS with message about
> hardware memory corruption fault. And after applying this series to our k=
ernel
> tree we cannot reproduce such SIGBUSes by our test. On upstream kernel 5.=
7
> this behavior is still reproducible.
>=20
> So, we want to know, why this patchset wasn't merged to the upstream?
> Is there any problems in such rework for {soft,hard}-offline handling?

No technical reason, it's just because I didn't have enough power to push
this to be merged. Really sorry about that.

> BTW, this patchset should be updated with upstream changes in mm.

I'm working this now and still need more testing to confirm, but I hope
I'll update and post this for 5.9.

Thanks,
Naoya Horiguchi=