On (02/02/15 15:18), Minchan Kim wrote: > > 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. > yeah, sorry. nevermind. So, guys, how about doing it differently, in less lines of code, hopefully. Don't move reset_store()'s work to zram_reset_device(). Instead, move set_capacity(zram->disk, 0); revalidate_disk(zram->disk); out from zram_reset_device() to reset_store(). this two function are executed only when called from reset_store() anyway. this also will let us drop `bool reset capacity' param from zram_reset_device(). so we will do in reset_store() mutex_lock(bdev->bd_mutex); fsync_bdev(bdev); zram_reset_device(zram); set_capacity(zram->disk, 0); mutex_unlock(&bdev->bd_mutex); revalidate_disk(zram->disk); bdput(bdev); and change zram_reset_device(zram, false) call to simply zram_reset_device(zram) in __exit zram_exit(void). -ss -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>