From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:42369 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S933110AbWLaJqi (ORCPT ); Sun, 31 Dec 2006 04:46:38 -0500 Date: Sun, 31 Dec 2006 01:46:30 -0800 (PST) Message-Id: <20061231.014630.130845911.davem@davemloft.net> Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again From: David Miller In-Reply-To: <20061231092318.GA1702@flint.arm.linux.org.uk> References: <20061230224604.GA3350@flint.arm.linux.org.uk> <20061230.212338.92583434.davem@davemloft.net> <20061231092318.GA1702@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org To: rmk+lkml@arm.linux.org.uk Cc: torvalds@osdl.org, miklos@szeredi.hu, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, akpm@osdl.org List-ID: From: Russell King Date: Sun, 31 Dec 2006 09:23:18 +0000 > We do this on ARM - if page_mapping() is NULL, we flush the kernel > alias unconditionally. However, we have no view where the user > mapping of that page is, which is where the problem is. Cache lines > remain allocated for the user mapping and data contained within is > not visible via the kernel mapping. You can walk the RMAP list. > However, it's not only FUSE which is suffering - direct-IO also doesn't > work. If my analysis is correct, only _two_ users of get_user_pages() > with the current process actually does the right thing and that's ptrace > and ELF core dumping. All other users are buggy. I do not argue that these cases need work, in fact I am aware of the direct-IO bit.