On Mon, Feb 02, 2015 at 02:59:23PM +0900, Sergey Senozhatsky wrote: > 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.
Sorry, I don't get it. Could you describe what you are concerning about active I/O? My concern is just race bd_holder/bd_openers and bd_holders of zram check. I don't think any simple solution without bd_mutex. If we can close the race, anything could be a solution. If we close the race, we should return -EBUSY if anyone is opening the zram device so bd_openers check would be better than bd_holders. > > -ss -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
