Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423002AbWLUSMI (ORCPT ); Thu, 21 Dec 2006 13:12:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1423004AbWLUSMH (ORCPT ); Thu, 21 Dec 2006 13:12:07 -0500 Received: from caramon.arm.linux.org.uk ([217.147.92.249]:2969 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423002AbWLUSMF (ORCPT ); Thu, 21 Dec 2006 13:12:05 -0500 Date: Thu, 21 Dec 2006 18:11:56 +0000 From: Russell King To: Miklos Szeredi Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again Message-ID: <20061221181156.GG3958@flint.arm.linux.org.uk> Mail-Followup-To: Miklos Szeredi , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org References: <20061221152621.GB3958@flint.arm.linux.org.uk> <20061221171739.GE3958@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2533 Lines: 59 On Thu, Dec 21, 2006 at 06:55:47PM +0100, Miklos Szeredi wrote: > > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That > > > could be replaced by the flush_kernel_dcache_page() (added by James > > > Bottomley together with flush_anon_page()) when all relevant > > > architectures have defined it. > > > > I should say that flush_anon_page() in its current form is going to be > > problematic for ARM. It is passed: > > > > 1. the struct page > > 2. the virtual address in process memory for the page > > > > It is not passed the mm or vma. This means that we have no idea whether > > the virtual address is in the currently mapped VM space or not. The > > common use of get_area_pages() is to get pages from other address > > spaces. > > I'm not sure I understand. flush_anon_page() needs only to flush the > mapping for the given virtual address, no? Yes, but that virtual /user/ address is meaningless without knowing which process address space it belongs to. > It's always mapped at that address (since it was just accessed through > that). No. Consider ptrace() (invoked by gdb) reading data from another processes address space to obtain structure data or instructions. > Any other mappings > of the anonymous page are irrelevant, they don't need to be flushed. Again, incorrect. Consider if the page you're accessing is a file- backed page, and is mapped into a process using a shared mapping. Because you've written to the file, those shared mappings need to see that write, and the interface for achieving that is flush_dcache_page(). If not, data loss can occur. > > If we use the supplied virtual address to perform cache maintainence of > > the userspace mapping, we might end up hitting a completely different > > processes address space, which may contain some page sensitive to such > > operations, or may not contain any page and thereby could cause a page > > fault on some ARM CPUs. > > I think calling get_user_pages() from a different process' address > space simply doesn't make any sense. That was it's main use - to implement ptrace() to read other processes address spaces. Why do you think it takes a task_struct and mm_struct? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/