Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965780AbbBCPFy (ORCPT ); Tue, 3 Feb 2015 10:05:54 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:51440 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751725AbbBCPFv (ORCPT ); Tue, 3 Feb 2015 10:05:51 -0500 Date: Wed, 4 Feb 2015 00:06:24 +0900 From: Sergey Senozhatsky To: Sergey Senozhatsky Cc: Ganesh Mahendran , sergey.senozhatsky.work@gmail.com, Minchan Kim , Andrew Morton , Jerome Marchand , linux-kernel Subject: Re: [PATCH] zram: fix umount-reset_store-mount race condition Message-ID: <20150203150624.GB1046@swordfish> References: <1422886120-16534-1-git-send-email-sergey.senozhatsky@gmail.com> <20150203141525.GA1050@swordfish> <20150203145200.GA1046@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150203145200.GA1046@swordfish> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1553 Lines: 53 On (02/03/15 23:52), Sergey Senozhatsky wrote: > On (02/03/15 23:15), Sergey Senozhatsky wrote: > > > How about keep this here? Protected by zram->init_lock. > > > set_capacity(zram->disk, 0); > > > > why? > > > yeah, I see why. good catch. > > hm, why do we perform destroy_device() before zram_reset_device() in > zram_exit()? > > how about doing something like this (I don't want to return > that bool param back): disregard the last one. this is done to remove sysfs before we do reset, so we don't race module unload with `echo 2G > /.../disksize', f.e. well, several options: 1) move ->init_lock from zram_reset_device() to its callers. iow, do down_write(&zram->init_lock); zram_reset_device(zram); up_write(&zram->init_lock); 2) remove sysfs group separate, before zram_reset_device() in zram_exit() sysfs_remove_group() zram_reset_device(); destroy_device(); 3) return back bool reset_capacity to zram_reset_device(). but this one is somewhat ungly. destroy() before reset() loks misleading, besides, after destroy() in zram_reset_device() we /* * Shouldn't access zram->disk after destroy_device * because destroy_device already released zram->disk. */ so we have garbaged ->disk pointer there, which is quite unsafe. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/