From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f69.google.com (mail-pa0-f69.google.com [209.85.220.69]) by kanga.kvack.org (Postfix) with ESMTP id 5DF6D6B007E for ; Thu, 2 Jun 2016 21:00:43 -0400 (EDT) Received: by mail-pa0-f69.google.com with SMTP id fg1so72980468pad.1 for ; Thu, 02 Jun 2016 18:00:43 -0700 (PDT) Received: from lgeamrelo12.lge.com (LGEAMRELO12.lge.com. [156.147.23.52]) by mx.google.com with ESMTP id l19si3744711pfb.167.2016.06.02.18.00.41 for ; Thu, 02 Jun 2016 18:00:42 -0700 (PDT) Date: Fri, 3 Jun 2016 10:01:29 +0900 From: Minchan Kim Subject: [PATCH] zsmalloc: zspage sanity check Message-ID: <20160603010129.GC3304@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky On Thu, Jun 02, 2016 at 09:25:19AM +0900, Minchan Kim wrote: > On Wed, Jun 01, 2016 at 04:09:26PM +0200, Vlastimil Babka wrote: > > On 06/01/2016 01:21 AM, Minchan Kim wrote: > > > > [...] > > > > > > > > Cc: Sergey Senozhatsky > > > Signed-off-by: Minchan Kim > > > > I'm not that familiar with zsmalloc, so this is not a full review. I was > > just curious how it's handling the movable migration API, and stumbled > > upon some things pointed out below. > > > > > @@ -252,16 +276,23 @@ struct zs_pool { > > > */ > > > #define FULLNESS_BITS 2 > > > #define CLASS_BITS 8 > > > +#define ISOLATED_BITS 3 > > > +#define MAGIC_VAL_BITS 8 > > > > > > struct zspage { > > > struct { > > > unsigned int fullness:FULLNESS_BITS; > > > unsigned int class:CLASS_BITS; > > > + unsigned int isolated:ISOLATED_BITS; > > > + unsigned int magic:MAGIC_VAL_BITS; > > > > This magic seems to be only tested via VM_BUG_ON, so it's presence > > should be also guarded by #ifdef DEBUG_VM, no? > > Thanks for the point. > > Then, I want to change it to BUG_ON because struct zspage corruption > is really risky to work rightly and want to catch on it in real product > which disable CONFIG_DEBUG_VM for a while until make the feature stable. Andrew, Please fold this patch into zsmalloc: page migration support. Thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751203AbcFCBAr (ORCPT ); Thu, 2 Jun 2016 21:00:47 -0400 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:43569 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751126AbcFCBAn (ORCPT ); Thu, 2 Jun 2016 21:00:43 -0400 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.204 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 3 Jun 2016 10:01:29 +0900 From: Minchan Kim To: Vlastimil Babka CC: Andrew Morton , , , Sergey Senozhatsky Subject: [PATCH] zsmalloc: zspage sanity check Message-ID: <20160603010129.GC3304@bbox> MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/03 10:00:40, Serialize by Router on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/03 10:00:40, Serialize complete at 2016/06/03 10:00:40 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 02, 2016 at 09:25:19AM +0900, Minchan Kim wrote: > On Wed, Jun 01, 2016 at 04:09:26PM +0200, Vlastimil Babka wrote: > > On 06/01/2016 01:21 AM, Minchan Kim wrote: > > > > [...] > > > > > > > > Cc: Sergey Senozhatsky > > > Signed-off-by: Minchan Kim > > > > I'm not that familiar with zsmalloc, so this is not a full review. I was > > just curious how it's handling the movable migration API, and stumbled > > upon some things pointed out below. > > > > > @@ -252,16 +276,23 @@ struct zs_pool { > > > */ > > > #define FULLNESS_BITS 2 > > > #define CLASS_BITS 8 > > > +#define ISOLATED_BITS 3 > > > +#define MAGIC_VAL_BITS 8 > > > > > > struct zspage { > > > struct { > > > unsigned int fullness:FULLNESS_BITS; > > > unsigned int class:CLASS_BITS; > > > + unsigned int isolated:ISOLATED_BITS; > > > + unsigned int magic:MAGIC_VAL_BITS; > > > > This magic seems to be only tested via VM_BUG_ON, so it's presence > > should be also guarded by #ifdef DEBUG_VM, no? > > Thanks for the point. > > Then, I want to change it to BUG_ON because struct zspage corruption > is really risky to work rightly and want to catch on it in real product > which disable CONFIG_DEBUG_VM for a while until make the feature stable. Andrew, Please fold this patch into zsmalloc: page migration support. Thanks! >>From 6b8fa9889b7892bdf5b2f01698310cfc766c4d17 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Fri, 3 Jun 2016 09:54:03 +0900 Subject: [PATCH] zsmalloc: zspage sanity check The zsmalloc page migration is new feature so I want to catch any corruption of zspage struct which is very critical to work regardless of CONFIG_DEBUG_VM. Signed-off-by: Minchan Kim --- mm/zsmalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index a80100db16d6..f75d2d134741 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -523,7 +523,7 @@ static void get_zspage_mapping(struct zspage *zspage, unsigned int *class_idx, enum fullness_group *fullness) { - VM_BUG_ON(zspage->magic != ZSPAGE_MAGIC); + BUG_ON(zspage->magic != ZSPAGE_MAGIC); *fullness = zspage->fullness; *class_idx = zspage->class; @@ -857,7 +857,7 @@ static struct zspage *get_zspage(struct page *page) { struct zspage *zspage = (struct zspage *)page->private; - VM_BUG_ON(zspage->magic != ZSPAGE_MAGIC); + BUG_ON(zspage->magic != ZSPAGE_MAGIC); return zspage; } -- 1.9.1