Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752981AbbLHVaX (ORCPT ); Tue, 8 Dec 2015 16:30:23 -0500 Received: from mail-qg0-f43.google.com ([209.85.192.43]:36481 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbbLHVaV (ORCPT ); Tue, 8 Dec 2015 16:30:21 -0500 MIME-Version: 1.0 In-Reply-To: <20151127101611.GA1087@gmail.com> References: <02ef9e0e0b73591aa8ec37aae2409274d108af60.1447093569.git.tony.luck@intel.com> <20151112075313.GA5984@gmail.com> <20151112200106.GA32073@agluck-desk.sc.intel.com> <20151127101611.GA1087@gmail.com> Date: Tue, 8 Dec 2015 13:30:19 -0800 X-Google-Sender-Auth: FmFlCgLYyNoXUM5iHqS_a9spFgo Message-ID: Subject: Re: [PATCH 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks From: Dan Williams To: Ingo Molnar Cc: "Luck, Tony" , Borislav Petkov , Linux Kernel Mailing List , linux-edac@vger.kernel.org, "the arch/x86 maintainers" , Jens Axboe , "Verma, Vishal L" , Jeff Moyer , "linux-nvdimm@lists.01.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1317 Lines: 34 [ adding nvdimm folks ] On Fri, Nov 27, 2015 at 2:16 AM, Ingo Molnar wrote: > > * Luck, Tony wrote: > >> On Thu, Nov 12, 2015 at 08:53:13AM +0100, Ingo Molnar wrote: >> > > +extern phys_addr_t mcsafe_memcpy(void *dst, const void __user *src, >> > > + unsigned size); >> > >> > So what's the longer term purpose, where will mcsafe_memcpy() be used? >> >> The initial plan is to use this for file systems backed by NVDIMMs. They will >> have a large amount of memory, and we have a practical recovery path - return >> -EIO just like legacy h/w. >> >> We can look for other places in the kernel where we read large amounts of memory >> and have some idea how to recover if the memory turns out to be bad. > > I see, that's sensible! > > Thanks, > > Ingo Is that an "Acked-by"? I'd like to pull this plus Vishal's gendisk-badblocks patches into a unified libnvdimm-error-handling branch. We're looking to have v4.5 able to avoid or survive nvdimm media errors through the pmem driver and DAX paths. -- 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/