From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hancock.sc.steeleye.com (stat1.steeleye.com [65.114.3.130]) by dsl2.external.hp.com (Postfix) with ESMTP id 828B34894 for ; Thu, 8 Apr 2004 09:28:59 -0600 (MDT) Received: from midgard.sc.steeleye.com (midgard.sc.steeleye.com [172.17.6.40]) by hancock.sc.steeleye.com (8.11.6/linuxconf) with ESMTP id i38FSia21905; Thu, 8 Apr 2004 11:28:44 -0400 Subject: Re: [parisc-linux] rmap: parisc __flush_dcache_page From: James Bottomley To: Andrea Arcangeli In-Reply-To: <20040408151415.GB31667@dualathlon.random> References: <1081435237.1885.144.camel@mulgrave> <20040408151415.GB31667@dualathlon.random> Content-Type: text/plain Date: 08 Apr 2004 10:28:44 -0500 Message-Id: <1081438124.2105.207.camel@mulgrave> Mime-Version: 1.0 Cc: Hugh Dickins , Linux Kernel , parisc-linux@parisc-linux.org List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2004-04-08 at 10:14, Andrea Arcangeli wrote: > you'd need to take a semaphore there to be safe, so it's basically > unfixable since you can't sleep or just trylock. That's a bit of an unhelpful suggestion. flush_dcache_page() exists to support coherency problems with virtual aliasing and a feature of that is that you have to flush every inequivalent user address which might be cached, hence the need for list traversal. Exactly why wouldn't a simple spinlock to protect page->mapping work? I know we don't want to bloat struct page, but such a thing could go in struct address_space? James