From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932512AbbBBF72 (ORCPT ); Mon, 2 Feb 2015 00:59:28 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:61744 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751470AbbBBF70 (ORCPT ); Mon, 2 Feb 2015 00:59:26 -0500 Date: Mon, 2 Feb 2015 14:59:23 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , "linux-kernel@vger.kernel.org" , Linux-MM , Nitin Gupta , Jerome Marchand , Ganesh Mahendran Subject: Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request Message-ID: <20150202055923.GA332@swordfish> References: <20150202034100.GF6402@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202034100.GF6402@blaptop> 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 On (02/02/15 12:41), Minchan Kim wrote: > > If we use zram as block device itself(not a fs or swap) and open the > > block device as !FMODE_EXCL, bd_holders will be void. > > > > Another topic: As I didn't see enough fs/block_dev.c bd_holders in zram > > would be mess. I guess we need to study hotplug of device and implement > > it for zram reset rather than strange own konb. It should go TODO. :( > > Actually, I thought bd_mutex use from custom driver was terrible idea > so we should walk around with device hotplug but as I look through > another drivers, they have used the lock for a long time. > Maybe it's okay to use it in zram? > If so, Ganesh's patch is no problem to me although I didn't' review it in detail. > One thing I want to point out is that it would be better to change bd_holders > with bd_openers to filter out because dd test opens block device as !EXCL > so bd_holders will be void. > > What do you think about it? > a quick idea: can we additionally move all bd flush and put work after zram_reset_device(zram, true) and, perhaps, replace ->bd_holders with something else? zram_reset_device() will not return until we have active IOs, pending IOs will be invalidated by ->disksize != 0. -ss