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