On Wed, Nov 20, 2013 at 8:59 PM, Weijie Yang <weijie.yang.kh@xxxxxxxxx> wrote: > Hello Dan > > On Thu, Nov 21, 2013 at 3:48 AM, Dan Streetman <ddstreet@xxxxxxxx> wrote: >> The changes in commit 0ab0abcf511545d1fddbe72a36b3ca73388ac937 >> introduce a bug in writeback, if an entry is in use by load >> it will be evicted anyway, which isn't correct (technically, >> the code currently in zbud doesn't actually care much what the >> zswap evict function returns, but that could change). > > Thanks for your work. Howerver it is not a bug. > > I have thought about this situation, and it will never happen. > If entry is being loaded, its corresponding page must be in swapcache > so zswap_get_swap_cache_page() will return ZSWAP_SWAPCACHE_EXIST ah, ok. While you do imply that with the fail: comment, I personally think it should also be stated in the refcount check comment; a comment indicating failure can happen due to concurrent load does not make clear that it will *always* fail in cases of concurrent load and so that case doesn't need to be checked for in the success path. Additionally, the lack of a check here is assuming that zswap won't be updated to ever inc the refcount anywhere besides the load function, which might cause unexpected breakage later; i.e., this is coding to the current implementation, not to the entry->refcount api. Can I also ask why you do a rb_search instead of just checking the entry->refcount? Doing the search is going to take longer than just checking the refcount; is there some case where the entry will not be in the rb but will have a nonzero refcount? -- 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>