Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761457AbXJLVtr (ORCPT ); Fri, 12 Oct 2007 17:49:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759539AbXJLVpv (ORCPT ); Fri, 12 Oct 2007 17:45:51 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]:47685 "EHLO rv-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760300AbXJLVpt (ORCPT ); Fri, 12 Oct 2007 17:45:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=COj8IzTg60YZn2+7+aUZ0IXLTYZ2QYtXCnl+H/R57nd9ag/LDAFJyRxUvMVYJRMcDc6rkRhkLCwfqA8e4BdnAjLjq7OOSrDscrQ7l3OMnC9hQtxr9DvqkzpCtPPcW8a/G80zhTJZv2mvzL7gMunQJNBuYyckzJGMv59zIkTc0qE= Message-ID: <84144f020710121445p23fcc21am18482e01856cdc35@mail.gmail.com> Date: Sat, 13 Oct 2007 00:45:48 +0300 From: "Pekka Enberg" To: "Hugh Dickins" Subject: Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland Cc: "Ryan Finnie" , "Andrew Morton" , "Erez Zadok" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, cjwatson@ubuntu.com, linux-mm@kvack.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710071920.l97JKJX5018871@agora.fsl.cs.sunysb.edu> <20071011144740.136b31a8.akpm@linux-foundation.org> X-Google-Sender-Auth: 5e3e3e8d36160be5 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 866 Lines: 19 Hi Hugh, On 10/12/07, Hugh Dickins wrote: > But I keep suspecting that the answer might be the patch below (which > rather follows what drivers/block/rd.c is doing). I'm especially > worried that, rather than just AOP_WRITEPAGE_ACTIVATE being returned > to userspace, bad enough in itself, you might be liable to hit that > BUG_ON(page_mapped(page)). shmem_writepage does not expect to be > called by anyone outside mm/vmscan.c, but unionfs can now get to it? Doesn't msync(2) get to it via mm/page-writeback.c:write_cache_pages() without unionfs even? Pekka - 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/