On Wed, Jan 25, 2017 at 12:26 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote: > On Tue, Jan 24, 2017 at 11:06:51PM -0500, Chulmin Kim wrote: >> On 01/23/2017 12:40 AM, Minchan Kim wrote: >> >On Mon, Jan 23, 2017 at 02:30:56PM +0900, Sergey Senozhatsky wrote: >> >>On (01/23/17 14:22), Minchan Kim wrote: >> >>[..] >> >>>>Anyway, I will let you know the situation when it gets more clear. >> >>> >> >>>Yeb, Thanks. >> >>> >> >>>Perhaps, did you tried flush page before the writing? >> >>>I think arm64 have no d-cache alising problem but worth to try it. >> >>>Who knows :) >> >> >> >>I thought that flush_dcache_page() is only for cases when we write >> >>to page (store that makes pages dirty), isn't it? >> > >> >I think we need both because to see recent stores done by the user. >> >I'm not sure it should be done by block device driver rather than >> >page cache. Anyway, brd added it so worth to try it, I thought. :) >> > >> >> Thanks for the suggestion! >> It might be helpful >> though proving it is not easy as the problem appears rarely. >> >> Have you thought about >> zram swap or zswap dealing with self modifying code pages (ex. JIT)? >> (arm64 may have i-cache aliasing problem) > > It can happen, I think, although I don't know how arm64 handles it. > >> >> If it is problematic, >> especiallly zswap (without flush_dcache_page in zswap_frontswap_load()) may >> provide the corrupted data >> and even swap out (compressing) may see the corrupted data sooner or later, >> i guess. > > try_to_unmap_one calls flush_cache_page which I hope to handle swap-out side > but for swap-in, I think zswap need flushing logic because it's first > touch of the user buffer so it's his resposibility. Hmm, I don't think zswap needs to, because all the cache aliases were flushed when the page was written out. After that, any access to the page will cause a fault, and the fault will cause the page to be read back in (via zswap). I don't see how the page could be cached at any time between the swap write-out and swap read-in, so there should be no need to flush any caches when it's read back in; am I missing something? > > Thanks. > > -- > 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> > -- 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>
