On Mon, 2007-10-15 at 11:51 -0400, Trond Myklebust wrote: > On Mon, 2007-10-15 at 15:06 +0100, David Howells wrote: > > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > I get funny SIGBUS' like so: > > > > > > fault > > > if (->page_mkwrite() < 0) > > > nfs_vm_page_mkwrite() > > > nfs_write_begin() > > > nfs_flush_incompatible() > > > nfs_wb_page() > > > nfs_wb_page_priority() > > > nfs_sync_mapping_wait() > > > nfs_wait_on_request_locked() > > > nfs_wait_on_request() > > > nfs_wait_bit_interruptible() > > > return -ERESTARTSYS > > > SIGBUS > > > > > > trying to figure out what to do about this... > > > > > > > Hmmm... It sounds like the fault handler should deliver the appropriate > > signal, should ->page_mkwrite() return ERESTARTSYS, and then retry the > > access > > instruction that caused the fault when the signal handler has finished > > running. > > If you signal the process before msync() has completed, or before you > have completed unmapping the region then your writes can potentially be > lost. Why should we be providing any guarantees beyond that?
Good point, I'm trying to figure out where my signal is comming from. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
