On Wed, Jan 28, 2015 at 12:53:54PM +0900, Sergey Senozhatsky wrote: > On (01/28/15 11:57), Minchan Kim wrote: > [..] > > > second, > > > after kick_all_cpus_sync() new RW operations will see false init_done(). > > > bdev->bd_holders protects from resetting device which has read/write > > > operation ongoing on the onther CPU. > > > > > > I need to refresh on how ->bd_holders actually incremented/decremented. > > > can the following race condition take a place? > > > > > > CPU0 CPU1 > > > reset_store() > > > bdev->bd_holders == false > > > zram_make_request > > > -rm- down_read(&zram->init_lock); > > > init_done(zram) == true > > > zram_reset_device() valid_io_request() > > > __zram_make_request > > > down_write(&zram->init_lock); zram_bvec_rw > > > [..] > > > set_capacity(zram->disk, 0); > > > zram->init_done = false; > > > kick_all_cpus_sync(); zram_bvec_write or zram_bvec_read() > > > zram_meta_free(zram->meta); > > > zcomp_destroy(zram->comp); zcomp_compress() or zcomp_decompress() > > > > You're absolutely right. I forgot rw path is blockable so > > kick_all_cpus_sync doesn't work for our case, unfortunately. > > So, I want to go with srcu. Do you agree? or another suggestion? > > yes, I think we need to take a second look on srcu approach. > > -ss Another idea is to introduce atomic refcount on zram for meta's lifetime management so that rw path should get a ref for right before using the meta and put it on done. If the refcount is negative, anyone shouldn't go with it. However, I guess we can do it simple and more scalable with srcu rather than introducing new atomic count. ;-) -- Kind regards, Minchan Kim -- 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>