On (09/10/13 17:34), Sergey Senozhatsky wrote: [..] > > > > Now I think we can drop the call to handle_pending_slot_free() in > > zram_bvec_rw() altogether. As long as the write lock is held when > > handle_pending_slot_free() is called, there is no race. It's no different > > from any write request and the current code handles R/W concurrency > > already. > > Yes, I think that can work. > > To summarize, there should be 3 patches: > 1) handle_pending_slot_free() in zram_bvec_rw() (as suggested by Jerome Marchand) > 2) handle_pending_slot_free() race with reset (found by Dan Carpenter) > 3) drop init_done and use init_done() > > I'll prepare a patches later today. I've sent two patches: staging: zram: fix handle_pending_slot_free() and zram_reset_device() race staging: zram: remove init_done from zram struct (v3) Cc'd driverdev-devel@xxxxxxxxxxxxxxxxxxxxxx as suggested by Dan. please discard any previous patches and sorry for the noise. Thanks, -ss > > > Jerome > > > > > > > >> > > >> 1) You haven't given us any performance numbers so it's not clear if the > > >> locking is even a problem. > > >> > > >> 2) The v2 patch introduces an obvious deadlock in zram_slot_free() > > >> because now we take the rw_lock twice. Fix your testing to catch > > >> this kind of bug next time. > > >> > > >> 3) Explain why it is safe to test zram->slot_free_rq when we are not > > >> holding the lock. I think it is unsafe. I don't want to even think > > >> about it without the numbers. > > >> > > >> regards, > > >> dan carpenter > > >> > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
