From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: Odd NFS related SIGBUS (& possible fix) Date: Sat, 02 Oct 2010 06:53:27 +1000 Message-ID: <1285966407.2463.145.camel@pasglop> References: <1285734825.14081.87.camel@pasglop> <1285956768.30373.39.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Nick Piggin , "linux-kernel@vger.kernel.org" , Al Viro , linux-fsdevel@vger.kernel.org To: Trond Myklebust Return-path: Received: from gate.crashing.org ([63.228.1.57]:45010 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753278Ab0JAUxi (ORCPT ); Fri, 1 Oct 2010 16:53:38 -0400 In-Reply-To: <1285956768.30373.39.camel@heimdal.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2010-10-01 at 14:12 -0400, Trond Myklebust wrote: > > However, it looks to me as if the right thing to do when the > page->mapping has changed would be to do the same thing as > block_page_mkwrite(), and just return VM_FAULT_NOPAGE so that the VM > can > retry the fault. > IMO: We should only SIGBUS if the calls to nfs_flush_incompatible() > and/or nfs_updatepage() fail. Well, other filesystems seem to think that if the mapping -changed-, SIGBUS is a good idea... But they don't have to deal with invalidations wiping mappings in the background. So that's why I was thinking about singling out the "mapping became NULL" case and keep the SIGBUS for when the mapping became something else... but that's your call really :-) Cheers, Ben.