On (01/24/17 23:06), Chulmin Kim wrote: [..] > > > > 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. :) Cc Dan, Seth (https://marc.info/?l=linux-mm&m=148514896820940) > 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) > > 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. hm, interesting. there is a report of zswap_frontswap_load() failing to decompress the page: https://marc.info/?l=linux-mm&m=148468457306971 -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>
