Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1170872AbdDXNQN (ORCPT ); Mon, 24 Apr 2017 09:16:13 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33737 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1170859AbdDXNQF (ORCPT ); Mon, 24 Apr 2017 09:16:05 -0400 Subject: Re: [RFC 1/2] mm: Uncharge poisoned pages To: Naoya Horiguchi References: <1492680362-24941-1-git-send-email-ldufour@linux.vnet.ibm.com> <1492680362-24941-2-git-send-email-ldufour@linux.vnet.ibm.com> <20170424090530.GA31900@hori1.linux.bs1.fc.nec.co.jp> Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" From: Laurent Dufour Date: Mon, 24 Apr 2017 15:15:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170424090530.GA31900@hori1.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17042413-0016-0000-0000-00000485DB8E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17042413-0017-0000-0000-00002760390B Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-24_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704240233 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1611 Lines: 48 On 24/04/2017 11:05, Naoya Horiguchi wrote: > 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. Thanks for the review, I will add the BUG's output in the next version. > >> >> 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. I move the call to memcg_kmem_uncharge() outside if (!isolate_lru_page(p)) and it seems to work as well. I'll wait a bit for any other review to come and I'll send a new version. Thanks, Laurent.