Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1167592AbdDXJHX convert rfc822-to-8bit (ORCPT ); Mon, 24 Apr 2017 05:07:23 -0400 Received: from tyo162.gate.nec.co.jp ([114.179.232.162]:41815 "EHLO tyo162.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1167573AbdDXJHH (ORCPT ); Mon, 24 Apr 2017 05:07:07 -0400 From: Naoya Horiguchi To: Laurent Dufour CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" Subject: Re: [RFC 1/2] mm: Uncharge poisoned pages Thread-Topic: [RFC 1/2] mm: Uncharge poisoned pages Thread-Index: AQHSubgolDF/QSaEhk6gnu6AvYpZ8qHTqYmA Date: Mon, 24 Apr 2017 09:05:31 +0000 Message-ID: <20170424090530.GA31900@hori1.linux.bs1.fc.nec.co.jp> References: <1492680362-24941-1-git-send-email-ldufour@linux.vnet.ibm.com> <1492680362-24941-2-git-send-email-ldufour@linux.vnet.ibm.com> In-Reply-To: <1492680362-24941-2-git-send-email-ldufour@linux.vnet.ibm.com> Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.30] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <47D2D236408D8143BC06CDC612AB9BB9@gisp.nec.co.jp> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 39 On Thu, Apr 20, 2017 at 11:26:01AM +0200, Laurent Dufour wrote: > When page are poisoned, they should be uncharged from the root memory > cgroup. Could you include some information about what problem this patch tries to solve? # I know that you already explain it in patch 0/2, so you can simply # copy from it. > > Signed-off-by: Laurent Dufour > --- > mm/memory-failure.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 27f7210e7fab..00bd39d3d4cb 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -530,6 +530,7 @@ static const char * const action_page_types[] = { > static int delete_from_lru_cache(struct page *p) > { > if (!isolate_lru_page(p)) { > + memcg_kmem_uncharge(p, 0); This function is supposed to be called with if (memcg_kmem_enabled()) check, so could you do like below? + if (memcg_kmem_enabled()) + memcg_kmem_uncharge(p, 0); And I feel that we can call this function outside if (!isolate_lru_page(p)) block, because isolate_lru_page could fail and then the error page is left incompletely isolated. Such error page has PageHWPoison set, so I guess that the reported bug still triggers on such case. Thanks, Naoya Horiguchi