Hi Dan, On Tue, Jan 31, 2017 at 08:09:53AM -0500, Dan Streetman wrote: > On Mon, Jan 30, 2017 at 7:10 PM, Minchan Kim <minchan@xxxxxxxxxx> wrote: > > Hi Dan, > > > > On Thu, Jan 26, 2017 at 12:04:03PM -0500, Dan Streetman wrote: > >> 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? > > > > Documentation/cachetlb.txt says > > > > void flush_dcache_page(struct page *page) > > > > Any time the kernel writes to a page cache page, _OR_ > > the kernel is about to read from a page cache page and > > user space shared/writable mappings of this page potentially > > exist, this routine is called. > > > > For swap-in side, I don't see any logic to prevent the aliasing > > problem. Let's consider other examples like cow_user_page-> > > copy_user_highpage. For architectures which can make aliasing, > > it has arch specific functions which has flushing function. > > COW works with a page that has a physical backing. swap-in does not. > COW pages can be accessed normally; swapped out pages cannot. > > > > > IOW, if a kernel makes store operation to the page which will > > be mapped to user space address, kernel should call flush function. > > Otherwise, user space will miss recent update from kernel side. > > as I said before, when it's swapped out caches are flushed, and the > page mapping invalidated, so it will cause a fault on any access, and > thus cause swap to re-load the page from disk (or zswap). So how > would a cache of the page be created after swap-out, but before > swap-in? It's not possible for user space to have any caches to the > page, unless (as I said) I'm missing something? I'm saying H/W cache, not S/W cache. Please think over VIVT architecture. The virtual address kernel is using for store is different with the one user will use so it's cache-aliasing candidate. 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>
