From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753781AbcARHJk (ORCPT ); Mon, 18 Jan 2016 02:09:40 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:46240 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214AbcARHJh (ORCPT ); Mon, 18 Jan 2016 02:09:37 -0500 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.76 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Mon, 18 Jan 2016 16:11:57 +0900 From: Minchan Kim To: Sergey Senozhatsky CC: Junil Lee , ngupta@vflare.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz Subject: Re: [PATCH v3] zsmalloc: fix migrate_zspage-zs_free race condition Message-ID: <20160118071157.GD7453@bbox> References: <1453095596-44055-1-git-send-email-junil0814.lee@lge.com> <20160118063611.GC7453@bbox> <20160118065434.GB459@swordfish> MIME-Version: 1.0 In-Reply-To: <20160118065434.GB459@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB02/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/01/18 16:09:34, Serialize by Router on LGEKRMHUB02/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/01/18 16:09:34, Serialize complete at 2016/01/18 16:09:34 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 Mon, Jan 18, 2016 at 03:54:34PM +0900, Sergey Senozhatsky wrote: > On (01/18/16 15:36), Minchan Kim wrote: > [..] > > > --- a/mm/zsmalloc.c > > > +++ b/mm/zsmalloc.c > > > @@ -1635,8 +1635,8 @@ static int migrate_zspage(struct zs_pool *pool, struct size_class *class, > > > free_obj = obj_malloc(d_page, class, handle); > > > zs_object_copy(free_obj, used_obj, class); > > > index++; > > > + /* This also effectively unpins the handle */ > > > > As reply of Vlastimil, I relied that I guess it doesn't work. > > We shouldn't omit unpin_tag and we should add WRITE_ONCE in > > record_obj. > > > > As well, it's worth to dobule check with locking guys. > > I will send updated version. > > but would WRITE_ONCE() tell the compiler that there is a dependency? > __write_once_size() does not even issue a barrier for sizes <= 8 (our > case). > > include/linux/compiler.h > > static __always_inline void __write_once_size(volatile void *p, void *res, int size) > { > switch (size) { > case 1: *(volatile __u8 *)p = *(__u8 *)res; break; > case 2: *(volatile __u16 *)p = *(__u16 *)res; break; > case 4: *(volatile __u32 *)p = *(__u32 *)res; break; > case 8: *(volatile __u64 *)p = *(__u64 *)res; break; > default: > barrier(); > __builtin_memcpy((void *)p, (const void *)res, size); > barrier(); > } > } > > #define WRITE_ONCE(x, val) \ > ({ \ > union { typeof(x) __val; char __c[1]; } __u = \ > { .__val = (__force typeof(x)) (val) }; \ > __write_once_size(&(x), __u.__c, sizeof(x)); \ > __u.__val; \ > }) > > > so, even if clear_bit_unlock/test_and_set_bit_lock do smp_mb or > barrier(), there is no corresponding barrier from record_obj()->WRITE_ONCE(). > so I don't think WRITE_ONCE() will help the compiler, or am I missing > something? We need two things 1. compiler barrier 2. memory barrier. As compiler barrier, WRITE_ONCE works to prevent store tearing here by compiler. However, if we omit unpin_tag here, we lose memory barrier(e,g, smp_mb) so another CPU could see stale data caused CPU memory reordering. > > .... add a barrier() to record_obj()? > > -ss