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 -- 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>