Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
Is the documentation wrong? Yes. As I've already explained there is no guarantee that get_user_pages() is only called to obtain pages for the current process, and flush_anon_pages() is called irrespective of which user process is being 'got'. ok, it's easy enough to fix, I'm just trying to point out that it's being implemented on parisc according to the documentation. randolph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
Is the documentation wrong? Yes. As I've already explained there is no guarantee that get_user_pages() is only called to obtain pages for the current process, and flush_anon_pages() is called irrespective of which user process is being 'got'. ok, it's easy enough to fix, I'm just trying to point out that it's being implemented on parisc according to the documentation. randolph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
I understand now. I'm not sure how the PARISC implementation can be correct in this light. According to cachetlb.txt: void flush_anon_page(struct page *page, unsigned long vmaddr) When the kernel needs to access the contents of an anonymous page, it calls this function (currently only get_user_pages()). Note: flush_dcache_page() deliberately doesn't work for an anonymous page. The default implementation is a nop (and should remain so for all coherent architectures). For incoherent architectures, it should flush the cache of the page at vmaddr in the current user process. Is the documentation wrong? randolph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
I understand now. I'm not sure how the PARISC implementation can be correct in this light. According to cachetlb.txt: void flush_anon_page(struct page *page, unsigned long vmaddr) When the kernel needs to access the contents of an anonymous page, it calls this function (currently only get_user_pages()). Note: flush_dcache_page() deliberately doesn't work for an anonymous page. The default implementation is a nop (and should remain so for all coherent architectures). For incoherent architectures, it should flush the cache of the page at vmaddr in the current user process. Is the documentation wrong? randolph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [parisc-linux] Re: [2.6 patch] schedule obsolete OSS drivers for removal
> Stuart, Randolph, comments? > > 1. > http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30=markup sure, kill the OSS ad1889 driver. randolph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [parisc-linux] Re: [2.6 patch] schedule obsolete OSS drivers for removal
Stuart, Randolph, comments? 1. http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30view=markup sure, kill the OSS ad1889 driver. randolph - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
